This is very curious, I’m going to PM you a command to run on your device if you wouldn’t mind, so I can get in and have a poke around.
OK I think I have an idea what might be going on now. Can you talk me through the steps you took to flash the devices?
Sure Create the app, press “add device”, select the dev edition, I waited until is downloaded. I connected my Tinker S to the PC. I use Etcher to select the image and the drive (internal eMMC of the board) and then pressed Flash. I waited for the flashing and verification.
Then I connected to the ethernet and the power supply and here we are!
I have a kind of out of the topic question.
Do you know if I can run a Balena Ubunto image in the Tinker S?
should be some think like this:
balenalib/armv7hf-Ubuntu:trusty-build
Ok I think this is the problem. For the Tinker S board so I think you need to burn the image to an SD card and then insert that into the device which will in turn flash the internal eMMC; you will also need to ensure that the jumper between the 5V power supply and the HDMI connector is in the “MASKROM” mode. Once the flash has completed the device should power down, then you can remove the SD card and revert the jumper to “parking” mode.
Give this a go and let me know how you get on.
@wrboyce Its been 15 mins and the status is still “Flashin BalenaOS on internal media”. At the begining there was a porcentage bar, but it disapeared, so I connected to the device localy and run top, but I dont see any process using the resources.
any clue? it is normal? Can I use the same SD to configure several boards?
Unfortunately I have never used this board myself, so I’ve got no idea how long the flashing process should take. Let me see if I can grab someone more familiar to give us a hand.
Although fifteen minutes does seem excessive!
@aburbano our resident Asus Guru is currently out to lunch, but I’ll grab him when he is back so we can get you sorted.
Ok, so I just restarted twice and it seems to be working the first one!!! trying a second one. so I guess I was just not doing the right process. I will suggest changing in the tutorial when you say that we should flash the eMMC instead of the external SD card:
The next step is to flash the downloaded image onto your eMMC using Etcher , a simple, cross platform eMMC writer and validator. Once you have Etcher installed, start it up. To give Etcher access to your eMMC, your system may prompt you to grant administrative privileges.
To create a bootable balenaOS eMMC follow these steps:
- Click Select image and find your application’s balenaOS image file.
- If you haven’t already done so, insert your eMMC into your computer. Etcher will automatically detect it. If you have more than one eMMC inserted, you will need to select the appropriate one.
- Click the Flash! button.
Etcher will now prepare a bootable eMMC and validate that it was flashed correctly. This can take roughly 3 or more minutes depending on the quality of your eMMC. You’ll get a little ping when it’s done, and Etcher will safely eject the eMMC for you.
Hmm yeah, it seems there is a discrepancy between the getting started guide and the little bullet point instructions next to the popup when you click “add device”. That needs fixing!
Hi, some more feedback, maybe it helps with the context:
The Asus Tinker Board and Asus Tinker Board S are two different device types on our platform, but we are reconsidering that part. The difference between the two is that the Tinkerboard uses and SD card for storage, as for Tinkerboard S has onboard eMMC, and runs from that by default.
The confusion is that the Tinkerboard S image that we have works the way that: burn onto an SD card, flip the device’s switch to run from an SD card, and that card will flash the internal eMMC. (this is a so-called “flasher” image). The Tinkerboard (no S) image is a “non-flasher”, once it is burned on the SD card, it can run directly.
The Tinkerboard S can also, by the Aus’s Getting Started Guide be directly flashed by Etcher.
So what we recommend for you to try: use the Tinker Board image (non S), and use Etcher to flash onto the eMMC card directly if using a Tinker Board S device, or onto an SD card if a Tinker Board. No need to use our “Tinker Board S” image at all). Does this make sense? I both devices the non-flasher image would be the right one if you are writing direcly onto the final media that the device is going to run from. After the device is provisioned, internally both type of images are exactly the same inside.
We are discussing internally how to make this clearer, and sorry for the confusion. Please let us know if you have a chance to try it! Thanks!
Hi @imrehg,
Yes It make sense, I’m gonna try it and let you know!
Sounds good, cheers! We’ll keep you posted if we make any improvements as well!
My feedback is that both processes are working, meaning that 1) Flashing an “SD with the Tinker S version and then insert it into the board to finally flash it into the eMMC” and 2) Flashing directly the “Tinker (no S) version into the eMMC” are correctly provisioning and updating the Tinker S board.
Process 1:
Pros
1 SD card cand configure several boards without having to connect them to a PC, so for production is a better practice.
cons
Some times is falling the flash from the SD to the eMMC but a turning off/on the power supply solve it (Maybe is a power supply problem from my side, you might have to verify).
Process 2:
Pros
It is a faster way to have your Tinker S running It will be more useful for development.
Cons
You see you HW in the dashboard as a Tinker so maybe you can figure out a way to know which kind of board it is independently from the flashing process.
Hey @aburbano, thanks for the practical feedback. We’ll take these into account when discussing improvements internally.
We haven’t really seen flashing failures when the SD card method is used.
Also, for production, the Etcher-based flashing might still be very much viable, if you are interested you can check out Etcher Pro, that we are currently working on for similar mass provisioning case https://www.balena.io/etcher/pro/