Posts by _emanuel_

    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.

    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.

    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?

    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/ 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?

    The build in remotes work great. :)

    LED - still fishing...

    This is all build in a chain of drivers hanging on the "fp-dev" driver,

    the Led is not listed in /sys/devices/platform/leds/ like in mainline.

    The main task of this fp-dev driver is the communication with the manufacturer boot loader: shutdown / reboot / standby / wakeup / ... The boot loader always gets the reboot result = boot loader (0x8), regardless of whether I have Android, LibreElec, ... Enter "shutdown -h now" always arrives reboot bootloader. Unless I'm using the original kernel with the fp-dev. That's why I built the Android and the CE with the original kernel in order to be able to use the drivers. I suspect that the original boot loader omitted the reboot result somewhere else.

    Here I looked for the GPIOs with an on-off hack driver and multimeter. :D

    Will flash the update

    Suddenly the Exit menu started without turning on, starting on and off going in a loop, see log attached.

    I also had this in my build when I gave the DTB the



      (226.74 kB, downloaded 47 times, last: )