So i managed to fire up the serial debugging using UART X14.

After reset I get the above message and a STAT led color orange.
The question is: How to reset the board?

Uhh, that is bad news. Your device is stuck in the middle of the boot loader, with something preventing to load the last piece of it. I'm afraid that's a service case, unless you have a chance to apply the recovery described in https://github.com/siemens/meta-iot2050/tree/master/recipes-bsp/u-boot#recovering-a-bricked-device, means you have access to some compatible programmer.

How did you get there again? Would be good to understand what could have caused this.

So asking what the bin file is for was a good preparation 

No, i have no chance to invest a programmer as expensive as the device.

What happened: I tried to do a backup from the eMMC to a usb medium.

So, I thought to boot from the clean image of the sdcard, mount the usb medium and transfer my data from eMMC to usb using the dd command. When setting the fw_setenv variables to have the next boot from sdcard I noticed the error "environment not initialized" as I wrote in another thread. There was an answer that this was a bug and the image might be too old.

But that was after i looked here:

http://manpages.ubuntu.com/manpages/bionic/man8/fw_setenv.8.html

to clear the origin of this message and then here:

https://www.denx.de/wiki/view/DULG/HowCanIAccessUBootEnvironmentVariablesInLinux

how to probably initialize the conf file. Which somewhat worked but I must have done something wrong there.

Anyway: I got past the error message, set the env variable, reassured that it was set to mmc0 or mmc1 (don't know anymore) and rebooted with the result I described.

Then I ordered the uart cable and made the log dump.

My best guess is that the conf file did not properly point to the correct mtd device or had the correct offset numbers and so went down the drain.

Afterwards you are wiser:

https://elinux.org/U-boot_environment_variables_in_linux

last paragraph. One has been warned.

Yeah, sorry, that cliff to firmware destruction is indeed fairly close. I should have warned you. At least we understand now the reason for this state.

Please contact the support for further steps.

Ok.

Ah, which support shall I contact and what are they supposed to do?