Posts by _emanuel_

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.

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 better had to been reading first: If you can get u-boot sources it's simple to extract the FIPs.

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

Unfortunately I don't have any feedback yet.

I only know that they are very busy with something new, as the managing director told me.

Can you really stretch the bin?

I'll attach both of them.

uboot_dreamone.bin.zip

uboot_dreamtwo.bin.zip

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.

Commits · emanuel4you/u-boot · GitHub

Found it

Now I have built own dreambox u-boot with master

will share it later.

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've tested cainload:

GitHub - chewitt/u-boot at amlogic-2020.10

beelink gt-w400 + CONFIG_LZO

(works for dreambox)

but

GitHub - chewitt/u-boot at amlogic-2021.01

(does boot without Screen (black))

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?

Now I've got only kernel panic

So, new build bootloader acts a little bit better (rigth color). But still isscues with mounts

made a log and a nice picture

the box uses the same remote as the dreambox, but I'm not so far at all...

So I took a couple of nude photos, thank God the girl is still playing with me

https://photos.app.goo.gl/7mGqKxuFeikQSaKBA

By the way: I've also tested the Img on "dreamtv" (s905x2, u212) same manufacture, other vendor, android streaming box.

it has a real problem with mmc 0, it can load kernel form it, but the later mount fails and the /dev/mmcblk0 does not exists only mmc 1 (emmc).

The build in remotes work great.

LED - still fishing...

LibreELEC:/sys/devices/platform/leds/leds/blue:power # echo gpio > trigger
LibreELEC:/sys/devices/platform/leds/leds/blue:power # echo 0 > brightness
LibreELEC:/sys/devices/platform/leds/leds/blue:power # cat *
0
cat: read error: Is a directory
1
cat: read error: Is a directory
cat: read error: Is a directory
[none] rc-feedback kbd-scrolllock kbd-numlock kbd-capslock kbd-kanalock kbd-shiftlock kbd-altgrlock kbd-ctrllock kbd-altlock kbd-shiftllock kbd-shiftrlock kbd-ctrlllock kbd-ctrlrlock heartbeat gpio cpu cpu0 cpu1 cpu2 cpu3 cpu4 cpu5 activity default-on mmc2 mmc0 mmc1 rfkill-any rfkill-none 0.0:00:link 0.0:00:1Gbps 0.0:00:100Mbps 0.0:00:10Mbps rfkill0
OF_NAME=blue
OF_FULLNAME=/leds/blue
OF_COMPATIBLE_N=0
LibreELEC:/sys/devices/platform/leds/leds/blue:power # 

root@dreambox:/proc/stb/fp# ls
fp_version  led_blink  led_brightness  led_color  led_fade  nec_ir  phy_powered  rtc  wakeup_time  was_timer_wakeup
root@dreambox:/proc/stb/fp# cat *
1.12
000710ff
000000ff
00ffffff
00000007
00000001
01617649904
0
0
root@dreambox:/proc/stb/fp# 

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.

Post

RE: [9.X-devel] LibreELEC builds for g02ref/g18ref_th2 (Prima PM-6001, VS-IP166, VS-IP015, ...)

Update + Addon VFD Display (Prima PM-6001, VS-IP166 ) locale: en/de





Have fun

emanuel4you

March 4, 2019 at 10:35 PM

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

    gpio-keys-polled {
        compatible = "gpio-keys-polled";
        #address-cells = <1>;
        #size-cells = <0>;
        poll-interval = <100>;

        power-button {
            label = "power";
            linux,code = <KEY_POWER>;
            gpios = <&gpio_ao GPIOAO_3 GPIO_ACTIVE_HIGH>;
        };
    };

linux,rc-map-name = "rc-dreambox-one";

I would only use:

linux,rc-map-name = "rc-dreambox";

they are using the same ones.