This forum uses cookies
This forum makes use of cookies to store your login information if you are registered, and your last visit if you are not. Cookies are small text documents stored on your computer; the cookies set by this forum can only be used on this website and pose no security risk. Cookies on this forum also track the specific topics you have read and when you last read them. Please confirm whether you accept or reject these cookies being set.

A cookie will be stored in your browser regardless of choice to prevent you being asked this question again. You will be able to change your cookie settings at any time using the link in the footer.

Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
I think I brick the Tinker
#1
Hello forum,

in my search of incredible Smile stumble on a bad case. The eMMC is no more seen as disk.
I'm on an Archlinux OS, but it don't matter much, when I plug the Thinker over a USB, here are the results
Code:
$ dmesg |tail
[99634.396930]  sdc: sdc2
[99635.051956]  sdc:
[99641.255618]  sdb: sdb1 sdb6
[99641.269498]  sdc:
[99641.293447]  sdc:
[99643.494752]  sdc:
[100882.114701]  sdc: sdc1 sdc2
[100892.439106] usb 3-3: new high-speed USB device number 13 using xhci_hcd
[100892.579504] usb 3-3: New USB device found, idVendor=2207, idProduct=320a, bcdDevice= 1.00
[100892.579510] usb 3-3: New USB device strings: Mfr=0, Product=0, SerialNumber=0

$ lsusb
Bus 003 Device 013: ID 2207:320a

$ parted -l
Model: ATA SanDisk Ultra II (scsi)
Disk /dev/sda: 240GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:

Number  Start   End     Size    File system  Name       Flags
 1      1049kB  263MB   262MB   fat32        ESP        boot, esp
 2      263MB   21.3GB  21.0GB  ext4         Emergency
 3      21.3GB  63.2GB  41.9GB  ext4         Linux
 4      63.2GB  147GB   83.9GB  ext4         Home
 5      147GB   240GB   92.9GB  ext4         Data


Model: ATA Hitachi HTS72757 (scsi)
Disk /dev/sdb: 750GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags:

Warning: failed to translate partition name
Number  Start   End    Size    File system  Name   Flags                  
 1      1049kB  738GB  738GB   ext4         Store
 6      738GB   750GB  12.0GB  ntfs                hidden, diag

I wish I can boot from the SD and try to fix the matter. But in the worst case, what could be the cure ?

EDIT
It was a bit of scare, all solved.
After some experience I also wrote a document
Reply
#2
I fixed the problem, but I proceed this thread because is a bit cumbersome the way to solve it.
The case is about what the eMMC should contain and the risk to overwrite that. Then I asking the way to minimize the effort to recover the worst case.

As many as other media storage, the partition table might disappear, so the system may be able to find the non formatted media. But for the TB eMMC is a bit different, I think. It's all day that I'm trying to recover the loss. But I mean the recognition in particular, nothing to do about what I'm going to write on the eMMC partitions.
Then, here's my question, where are the information to keep, in order that the host computer can find the eMMC as storage media ?
Is it like a normal MBR or GPT scheme?
Even then, why the host system won't pick the plugged TB as media storage? Certain time the PID/VIP are missing ?
And when they aren't missing, then is not recognized as storage media.... Where to fix ?
Reply
#3
Hi,

If just the Tinker Board S' eMMC cannot be recognized from PC.
It may cause by the eMMC's U-Boot has been cleared (by format) or broken.
(Tinker use U-Boot to boot and mount eMMC as storage on PC)

More detail, please check below guide:
https://tinkerboarding.co.uk/wiki/index....ard_S_eMMC

And below is the one of most simple method to solve this problem:
https://tinkerboarding.co.uk/wiki/index....om_SD_card

1. Prepare one SD card, and flash new official system image into SD card.
2. Install the SD card into the board, and change jumper to recovery/maskrom mode.
3. Connect Tinker Board S by USB with PC.
4. The eMMC would be mount again on your PC by SD card's U-Boot.

And then you can start to re-flash a new image into eMMC again.
Also next time, it can mount as USB disk itself, because it already restored the UMS U-Boot by flash new image.
Reply
#4
(08-20-2018, 09:29 AM)Tinker Board Wrote: It may cause by the eMMC's U-Boot has been cleared (by format) or broken.

Well this is the primer cause, I'm preparing my own u-boot. So that is the question, what are the parts/function to preserve in order to maintain the USB-OTG function working?

Yesterday I repeatedly wrote the first 4 Mbytes, which contain miniloader, u-boot and more, then it returned to be recognizable by the host PC, but definitely the partition table is incongruent to what is written previously and the u-boot doesn't reflect the installation.

To me it seems that the TB S has a problem regarding the eMMC management, which is not read-only so we may incur in such trouble easily. Just to compare with a SD card or UMS, they aren't affected by that.


So, why not the BootRom contains that function ?
Reply
#5
(08-20-2018, 11:09 AM)Im4Tinker Wrote:
(08-20-2018, 09:29 AM)Tinker Board Wrote: It may cause by the eMMC's U-Boot has been cleared (by format) or broken.

Well this is the primer cause, I'm preparing my own u-boot. So that is the question, what are the parts/function to preserve in order to maintain the USB-OTG function working?

Yesterday I repeatedly wrote the first 4 Mbytes, which contain miniloader, u-boot and more, then it returned to be recognizable by the host PC, but definitely the partition table is incongruent to what is written previously and the u-boot doesn't reflect the installation.

To me it seems that the TB S has a problem regarding the eMMC management, which is not read-only so we may incur in such trouble easily. Just to compare with a SD card or UMS, they aren't affected by that.


So, why not the BootRom contains that function ?

Hi, Im4Tinker
    The BootRom is a ROM code which is pre-burned in the SoC and cannot be modified. The BootRom can support maskrom mode which is also a F/W flash mode.
    The maskrom mode is not a standard mode, so you will need a particular tool to flash eMMC by maskrom mode.
    And the UMS mode is a standard mode, it just likes the usb drive. You can access it by win32diskimager tool or etcher ...etc.
    We implement the UMS mode at the u-boot so if the u-boot is not exist, the UMS mode will not work.
    For example, user erases the u-boot partition by dd command. (The u-boot partition is located at offset 0x40 sector in eMMC)
    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 which user can get the root permission on Tinker Board S.
    We are very welcome if you have any idea can share to us. If it does work, we will glad to implement it to improve the user experience of eMMC flashing.
Reply
#6
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 Wink
  • 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.

james Wrote: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
Reply
#7
Hi Im4Tinker
    I am not sure if we talk about the same "BootRom". The BootRom I talked is a area that is exist in the SoC and it will pre-burn some code by the SoC vendor.
    And also it is one time programable, so we can't add any function at the BootRom.

    I know you use the 3rd-party u-boot without the ums function but I think we should have some convenient way to solve your problem.
    May I know your scenario ? Maybe I can based on your scenario and give you some options.
    For example, you want to update kernel/rootfs when the eMMC has no ums uboot.
Reply
#8
Thank you for feedback.
(08-21-2018, 07:43 AM)jamess Wrote: And also it is one time programmable.

Oh, I see. I supposed it is like a common flash like many other board (i.e. Arduthingy). I saw some document that mention the way to write that flash, which include some jumper position during power on and a male-to-male USB cable for writing the data.
Anyway, I suppose I'm wrong, so the RK3288 is OTP.

jamess Wrote:I know you use the 3rd-party u-boot without the ums function

Well, I'd express that humanity is not homogeneous, so there are who like banana, raspberry, orange and some other name SBCs. Then also for the distro that we all want to use, there are whom prefer Armbian, DietPi, Android and other. My intention is slightly different distro, so I'm looking to install ArchLinux ARM.

Most of the distros proposed here are debian derived, which gives me the feeling like a sea fish in a clear water. Definitely a different environment. The most differences are non modular kernel and a bloat of program to begin from, in most of the distros actually proposed.

For an Arch installation is just given the bases to begin, then every user has the full power to customize what to use. Of course, this is a hard impact for the masses, they're mostly have a low experience and want to see a ready-to-go setup, nothing to know about settings in a console. But that is the taste of the freedom to choose anything.
Therefore, for a little of us, we look for a SBC from the maker perspective, where the experience shouldn't lack and it could be a necessity to tailor the setup as one's content.

I'm using a hybrid setup, which has linaro kernel and Arch rootfs. There are no way to keep updated, as long as the kernel leads all functionalities.

Actually, I could achieve a prototype installation,which boots fairly good from a SD card. So the rest is just to refine certain module to work correctly. So at the beginning there were issues about the way to debug the u-boot because the serial monitoring wasn't working correctly. That's why we (Thanks to Mr. Summers at Archlinuxarm) started to arrange a modification to the boot procedure. And there started this side effect.
But we have used the tinker-rk3288_defconfig (from https://github.com/u-boot.git/configs/ti..._defconfig) and that includes the UMS mode. It is strange why is resulting always in a failure.

So, the very next step is to solve this problem, which disappointing me as much as I choose to buy the S version. Also to give one more distro to offer to the tinker's community.

There are difficulties to build the u-boot, because the kernel-headers are referred to a more recent kernel, compare the distros here. Further more the actual version of the kernel is 4.18 and the headers are 4.16. I don't know how these things will work together. It is all a big experiment, all are invited Wink

Looking forward to understand the procedure to build the u-boot, which may require me a steep learning curve.
Reply
#9
I'd like to add a bit more information. I got 95% solved the issue, which need to rewrite the u-boot with the help of Armbian patches.
Thank you to the Armbian staff !
[-] The following 1 user Likes Im4Tinker's post:
  • igorpec
Reply
#10
So I did this to the Tinkerboard S by mistake trying to install another OS, after doing the above steps its showing up again on my pc but I'm getting a error message in etcher saying that I don't have permission.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)