I think I brick the Tinker

[Im4Tinker]

If the eMMC visibility cannot be protected, it's a small issue. But I'd like to see the guidelines to write the code which recover that functionality.
It shouldn't be to have to write a TinkerOS again, if that is happened. One may have sensitive written data which a new re-installation might wipe out.
So for that event, I suggest to follow these steps.

• Save the first 4 eMMC megabytes after the first installation, whichever Distro chosen
  
  Code:

  $ sudo dd if=/dev/mmcblkX of=a_file_name bs=4M count=1
  Verify what name the kernel gives to the eMMC. X it should be the drive number point at eMMC. Pay attention to chose the entire drive, not a single partition
  

• When the functionality is lost, recover the saved 4 Mb, for the same installed Distro. Verify that the partitioning hasn't changed and apply the reverse operation:
  
  Code:

  $ sudo dd if=a_file_name of=/dev/mmcblkX
  Verify what name the kernel gives to the eMMC. X it should be the drive number point at eMMC. The file must be the previously saved one.
  

To whom, like me, wants to try to write a new u-boot, be warned that there's the risk to lose the USB-OTG function and then the eMMC is not found by a host PC when plugged. So I invite developers to guide us on the way to take care to prepare a u-boot compile.
There might be a file over some gigabyte of written documents explaining how to, but it's very appreciated to point me at.
Just to mention that  the u-boot's tinker3288_defconfig already contains PID and VID, but no kernel is able to identify the device as block one. Probably because of a part of the data handling must be carried out by the RK3288.

I agree with you that we can't give a chance that user can erase the u-boot partition, or the ums mode will not work.

    But we have no idea how to protect the u-boot part of eMMC

My point of view suggest to find room in the BootRom to save the eMMC's ums mode, because the access to BootRom is pretty complex operation, compare the eMMC writing.

In the other hand, it's clear that as open project, the user has the privileges to access to that part of the memory, unless the RK3288 is instructed that the address is write protected. And that area is exclusively used for the ums mode. Otherwise is likely what I'm looking for, the information that tells the risk (and the cure) to overwrite the ums functionality. Probably written in the Wiki page