[Solved] Asus TB S

This is for any ARMv7 device that we do not officially support.

[Solved] Asus TB S

Postby TheSaint » Mon Jul 23, 2018 8:42 am

Hello forum,
I'm new here, but I know about Arch more than a decade.

I just bought a Tinker Board S, which has a eMMC built-in. I don't like much the TinkerOS, so I would like to make my own steps, away from that OS.
On the other hand is rather complicated to set up services with such OS. I was expecting no needs for keyboard/display/mouse and to be able to go directly via ssh, wireless or wired. To much frustrations.

I read this post, but I doubt I can do the same on a eMMC.
The embedded MMC, works like a pendrive, once plugged into USB. But I can't figure out to arrange the kernel on the ESP, that the factory setup has. I've copied the kernel.part into ESP, but it doesn't work. I guess it should go somewhere/somehow different.
I have a lot to guess how extlinux,conf might permit dual booting.

I've coarsely read how the Rock3288 needs to be arranged for the boot, then it seems to me that is necessary some code in the first memory block to accommodate the first MCU steps. The I feel that the mentioned post lacks of details on how to prepare the boot loader and how to enable dual booting, if one wants it.

My intents are to set up a little server for home automation, so that might be a small footprint. I've been attracted by DietPI, which offer a plenty of alternatives, but it's a way which I don't like, a prepacked solution :!: :!:

Sorry for the rants, in a couple of days I just got nothing but frustrations.
EDIT
As of today September 5, 2018, the system is working and I also update to the latest packages.
There may be small issues, which I consider just a next step improvement.
Thanks to Mr Summers and the Armbian staff for the work done to achieve this.
Last edited by TheSaint on Wed Sep 05, 2018 5:02 am, edited 5 times in total.
TheSaint
 
Posts: 345
Joined: Mon Jul 23, 2018 7:57 am

Re: Asus TB S

Postby summers » Mon Jul 23, 2018 11:26 am

Well it has some obvious UART on the pin out - so I'd connect to those - and see if you can see the boot sequence.

Now looks probably it boots via arm secure boot, which is a hassle, but outside the secure bit calls through to uboot (hopefully).

Uboot you can then instruct to boot arch.

But first you need to understand what you can do in uboot, as you'll be stuck with that unless you crack the secure interface.
summers
 
Posts: 885
Joined: Sat Sep 06, 2014 12:56 pm

Re: Asus TB S

Postby TheSaint » Mon Jul 23, 2018 11:46 am

Fine, I've the tools to connect to the UART pins. Is there any additional parameter to pass to the kernel command line ?
Maybe debug ?
Anyway the kernel won't be much different, I wish I will get the Archlinux packaging method, which I like more.
Maybe I'll eradicate the TinkerOS and put Archlinux over it. Just to know where the TinkerOS starts first.
TheSaint
 
Posts: 345
Joined: Mon Jul 23, 2018 7:57 am

Re: Asus TB S

Postby summers » Mon Jul 23, 2018 12:09 pm

If it goes via uboot, you can normally interrupt the boot sequence with any key.

then "help" and "printenv" should show you want commands and what macros are available. That should give clues on the memory layout, etc.

The env variables may or may not be modifiable ...

You could then issue you own commands to bot arch via the usb probably. When that works look at transferring the the eMMC.
summers
 
Posts: 885
Joined: Sat Sep 06, 2014 12:56 pm

Re: Asus TB S

Postby TheSaint » Thu Jul 26, 2018 1:54 am

I got scared to plug the UART interface.
The LED of the power lit up prior to plug the power supply. I worry that any wrong current are going though the RX-TX pins.
TheSaint
 
Posts: 345
Joined: Mon Jul 23, 2018 7:57 am

Re: Asus TB S

Postby summers » Thu Jul 26, 2018 9:22 am

Lets answer both this and your other post in this thread.

For the UART you almost certainly need a 3.3V UARt to USB converter (so something the the FTDI RPi cabel). You need to connect GND,RX,TX , so do not connect VDD as yes sometimes that will power the board, and that isn't what you want.

Why do we want to see what the boot messages are, and in particular how uboot is configured. Uboot which boots the kernel has evolved over time, and depending on how it is configured. Usually it can read file systems, almost always FAT, for a long time ext2, and more recently ext4. Now which of those it can read changes how you set up the sd card.

So lets flip to your link http://opensource.rock-chips.com/wiki_Boot_option lower down it says:

Code: Select all
    For armv7 with SPL with SPL_BACK_TO_BROM option enabled(rk3036, rk3188, rk3288):

. dd if=idbloader.img of=sdb seek=64
. dd if=boot.img of=sdb seek=32768
. dd if=rootfs.img of=sdb seek=262144

    For armv7 with SPL with SPL_BACK_TO_BROM option disabled(rk3288):

. dd if=idbspl.img of=sdb seek=64
. dd if=u-boot.bin of=sdb seek=16384
. dd if=boot.img of=sdb seek=32768
. dd if=rootfs.img of=sdb seek=262144

So we can see that the rk3288 can seem to have two boot modes (SPL_BACK_TO_BROM), which you can use I don't know.

Now both of these seem to be setting up a separate boot partition as well as a root partition, this isn't unusual for arm. The root partition is usually ext4 formatted, but if uboot can't access ext4 then a separate boot partition that is either ext2 or FAT partitioned - which you need we don't yet know.

Now higher in that tread, says it probably loads a device tree as well as the kernel - thats good, at least its modern. So your boot partition probably needs at least a kernel plus a device tree - have checked what device tree is avaiable for your board.

Going back to the above, we can go more into the boot sequence of your board. The boot will first boot from ROM, and that will look somewhere for what to do next. Now sounds like your board is good enough that it looks both at the SD card slot as well as the eMMC. How it does this, and how it decides which to do, isn't clear.

Now the ROM probably just starts access the sd/eMMC from a set location, thats the 64 offset above. That also looks like it specific code for your board, either idbspl.img or idbloader.img - who can say what those do. The first goes via uboot, the second doesn't.

You'll need to get on top of all this to get a good boot set up. What the other thread did btw, is just take a working set up, and replace the rootfs only - so keeping all the boot set up from the working set up. Thats a way forward, but not very maintainable.

So how do you go about understanding your board, well I can't see much documentation, so attaching a UART and taking a look at whats printed there seems the easiest way.
summers
 
Posts: 885
Joined: Sat Sep 06, 2014 12:56 pm

Re: Asus TB S

Postby TheSaint » Thu Jul 26, 2018 8:22 pm

I'm so grateful for your explanation, THANK YOU!
Let's merge the post to this one.
I've tried to connect to the serial and for sure I've regarded to leave out the supply. My tool is built on a PL2303 and has output for 5 and 3.3 Volts.
Anyway, I was trying to connect the serial port (with a bit of doubt about which of the four available was to be connected) then I saw the power LED turning on, which might indicate a power return from unpredictable source.
I was trying to get the terminal up prior the TB starting, so I could have the chance to catch the output. Because the the USB-RS232 tool must be recognize and set up a terminal to see the data flow. That's way I tried to connect with the serial port already active.
So for for one point I'm confident that doesn't need a level converter, but I think for the sake of safe operations to try an opto-coupled connection. In such manner I won't face risks.

Lately on my attempt to get some result, I found that the boot sequence prioritize the eMMC, if it has a valid scheme to boot from. Because to boot from the SD card I zeroed the first 10 Mbytes on the eMMC.
I've to tried to compile the rkdeveloptool, but I stumble in an error, which I'm not that good to solve. So I couldn't try any step further.

I followed these instructions, but it didn't boot. Then I'll be back with the kernel reports and see for a chance.

EDIT
There's a way to change the boot priority. using the board jumpers.
TheSaint
 
Posts: 345
Joined: Mon Jul 23, 2018 7:57 am

Re: Asus TB S

Postby summers » Fri Jul 27, 2018 9:54 am

Yes a pl2303 device should work, so just make sure its in 3.3V mode and that only 3 pins connected, and you should be fine. Yes good idea to plug in the UART before powering the board, and start up the serial connection 115200 8N1 on the host computer before powering up the Asus TB S.

Before being powered, there should be no leds lit on the Asus TB S, so if the UART lights up any leds, then there is something wrong, so check carefully.

Starting from chromebook instructions isn't easiest - problem is chromebooks have their own boot mechanism - and its not the SBC typical set up.

Yes its a good idea to start from the veyron image: http://de3.mirror.archlinuxarm.org/os/ArchLinuxARM-veyron-latest.tar.gz, but I'd be tempted to start from OS that already works on the Asus TB S.

e.g. an OS that works will set up the partitions that it needs (probably a separate /boot partition as well as them root partition). Also it will set up the various boot code needed at the right point in the SD card (e.g. uboot somewhere, and the SPL or whatever loader it is at 0x40).

You then need to unpack the veyron arch linux package on the root fs, then make sure you copy the relevant files to the boot partition (viz kernel and device tree).

It will be far easier with the UART working btw, then you can see the boot messages, and so see what is going wrong ...
summers
 
Posts: 885
Joined: Sat Sep 06, 2014 12:56 pm

Re: Asus TB S

Postby TheSaint » Fri Jul 27, 2018 11:58 pm

Fine, I had a confirmation to prepare the serial on the Tinker Board. It takes to add some command to the kernel line for the TinkerOS.

I'll wait for a clear idea to connect without any strange current leakage.
I'm tempted to build a kernel, then I tried to set up the tools from AUR for my Arch on the laptop. But I found a couple of conflicts, so I couldn't realize the correct installation.

Well. I'll try to get the veyron image, and come back with some news.

Good News
I booted Alarm.
I formatted the TinkerOS root and copied Arch root in it. Then I left the old ESP and used the same kernel. I just modified a little the kernel line by removing the splash related things.

There's a small problem that the WiFi is not seen by the kernel. Perhaps I should look into /proc or /sys.
One more flaw is regarding to have no chances to boot headless. The SSH is running but the NIC is down. It's a bit of load to move back and forward to the TV-set, on the ways to arrange tings up.
TheSaint
 
Posts: 345
Joined: Mon Jul 23, 2018 7:57 am

Re: Asus TB S

Postby summers » Sat Jul 28, 2018 12:07 pm

Good that you booted arch. Have you found the boot partition yet? So you can see how its formatted, and also the file structure in the partition? uboot will look in specific places for the various boots files.

With the hardware that doesn't work, things to look at.
    . Has the device tree worked? e.g do you have "/proc/device-tree" and is it set to the right machine, e.g. my dmesg has near the top "[ 0.000000] OF: fdt: Machine model: ZyXEL NSA325" - so I can see it has loaded the device tree "fdt" of my machine NSA324 NAS. The device tree will describe your wifi and ethernet, so that may well be the problem. Oh yes you can also use "cat /proc/device-tree/model"
    . check dmesg carefully, so you can see what failed on boot, e.g. why hardware didn't come up

Hope that helps.

Oh yes checked a kernel I had arround = 4.11.3 - the only rk3288 device trees were:
Code: Select all
rk3288.dtsi                      rk3288-rock2-som.dtsi
rk3288-evb-act8846.dts           rk3288-rock2-square.dts
rk3288-evb.dtsi                  rk3288-veyron-analog-audio.dtsi
rk3288-evb-rk808.dts             rk3288-veyron-brain.dts
rk3288-fennec.dts                rk3288-veyron-chromebook.dtsi
rk3288-firefly-beta.dts          rk3288-veyron.dtsi
rk3288-firefly.dts               rk3288-veyron-jaq.dts
rk3288-firefly.dtsi              rk3288-veyron-jerry.dts
rk3288-firefly-reload-core.dtsi  rk3288-veyron-mickey.dts
rk3288-firefly-reload.dts        rk3288-veyron-minnie.dts
rk3288-miqi.dts                  rk3288-veyron-pinky.dts
rk3288-popmetal.dts              rk3288-veyron-sdmmc.dtsi
rk3288-r89.dts                   rk3288-veyron-speedy.dts


So not clear which you would use. Check your /boot/dtbs
Last edited by summers on Sun Jul 29, 2018 11:46 am, edited 4 times in total.
summers
 
Posts: 885
Joined: Sat Sep 06, 2014 12:56 pm

Next

Return to Community Supported

Who is online

Users browsing this forum: No registered users and 1 guest