[Solved] Asus TB S

[summers]

In developing arch for the pocket beagle, I spent some time browsing round uboot, and how it works. What I found best is sticking with the main line uboot where possible, there are several other versions branched out from the original - but I've always found them questionable. So place to start is whats done in mainline. This is a good read:

http://git.denx.de/?p=u-boot.git;a=tree;f=configs

I use the am335x_boneblack_defconfig for the pocket beagle.

But for you you would want:

http://git.denx.de/?p=u-boot.git;a=blob;f=configs/tinker-rk3288_defconfig

This suggests if you download mainline uboot, you should be able to do $this->bbcode_second_pass_code('', 'make tinker-rk3288_defconfig')

And see what files it makes. There will be some other files in uboot - hopefully some will have instructions of how to install on the tinker board ....

Ah yes, this is the /include/config file it uses - it shows how uboot will work on this build:

http://git.denx.de/?p=u-boot.git;a=blob;f=include/configs/rk3288_common.h

[TheSaint]

$this->bbcode_second_pass_quote('summers', 'T')his suggests if you download mainline uboot, you should be able to do
$this->bbcode_second_pass_code('', 'make tinker-rk3288_defconfig')

[summers]

The difficulty as I see it is that we have two ways of understanding how the tinkerboard boots, and how to install mainline arm arch to it:
1) Manage to get to the boot messages via UART, and learn enough that we can get it to boot mainline arm arch
2) examine the tinkerboardOS image carefully, and with info gained there and elsewhere on the net, create an sd image that boots
Now 1 is the easiest method, but we havn't managed to get it to work - and so probing on 2.

So we get questions about how the board boots, does it require an SPL/MLO before mainline uboot, do the images need packing in some format? etc...

This is where compiling uboot would give some clues, what images did it create in the top directory? Use "ls -lart" to see. Knowing what it creates we can look at what to do with them.

Looking at the TBOS image, can see code starting at 0x8000-0x81ff so limited payload there, and no informative text.

At 0x8800 looks like more extensive code, possibly uboot spl, text "U-Boot SPL 2016.09-rc1 (Apr 17 2017 - 17:24:50)" is a tad lower. But it looks like its packed in a header that starts "RK32" and padded to 32 bytes - what this is I don't know.

Possible device tree at 0xd660.

Uboot proper (the .bin file) seems to be at 0x10800

Now you can see the problems with this approach - we don't know what we are looking at.

Oh yes you questioned if the machine is comming up, just without hdmi. Easy way to check is that the kernel when it starts will start a heart beat. From the device tree:
$this->bbcode_second_pass_code('', 'heartbeat-led {
gpios=<&gpio1 RK_PD1 GPIO_ACTIVE_HIGH>;
linux,default-trigger="heartbeat";
};')
So an led somewhere should be flashing when the kernel comes up. You should see this in TBOS, but can also use it when testing as the heartbeat is very low level.

The problem with extlinux is that we don't have any idea what code this is based on. It could be anything, as extlinux is non standard for arm. Without access to the code, who can say whats its doing? How can it de debugged or configured?

Oh yes the uboot code is useful, so you can learn how uboot is set up - for TB it doesn't like like there are many compiled in environment variables (e.g. compare to the beagle bone black file). So this probably means it is doing via environment variables that it saves to the sd card somewhere - so need to understand that. also note that the default dtb is the tinker one, looking at the change logs, you can see that miniarm was the working name inside rockchip; but when the board was released its name was changed to tinker board. So that explains the device tree naming ....

$this->bbcode_second_pass_quote('summers', '1')) Manage to get to the boot messages via UART

[summers]

Looks like 0x8800 is the u-boot spl. This is given by crytic byte matching.

Oh yes the full leds in the device tree are
$this->bbcode_second_pass_code('', 'gpio-leds {
compatible = "gpio-leds";

act-led {
gpios=<&gpio1 RK_PD0 GPIO_ACTIVE_HIGH>;
linux,default-trigger="mmc0";
};

heartbeat-led {
gpios=<&gpio1 RK_PD1 GPIO_ACTIVE_HIGH>;
linux,default-trigger="heartbeat";
};

pwr-led {
gpios = <&gpio0 RK_PA3 GPIO_ACTIVE_HIGH>;
linux,default-trigger = "default-on";
};
};')
So yes looks like one is active on mmc0 which is probably the EMMC, that I would guess flashes faster than the heatbeat which is something like 2Hz.

[TheSaint]

There is the schematic, but I couldn't see where the heartbit LED is connected, which is yellow. I also can't recall whether is turning on sometime.
The documentation tells some important point regarding the extlinux. So I'm studying what could be the chance to modify the one I'm using. Also this doc explain some more.
Off course there might be a dependence in how the SPL is configured too.

I've tested some hardware in order to hook a debug on an UART. But it seems I don't have a good adapter, therefore I ordered a brand new one. Within this week I hope to read from the UART
I'm immerse on studies

[summers]

Good spot that that u-boot/distro makes uboot act like syslinux/extlinux. Its strange though don't think I've ever seen "CONFIG_DISTRO_DEFAULTS=y" enabled, e.g. the tinker config doesn't have it: http://git.denx.de/?p=u-boot.git;a=blob;f=configs/tinker-rk3288_defconfig

From digging I've done. It seems cleat that the boot sequence is:

1) Boot Rom
2) U-boot-SPL
3) Boot Rom
4) U-boot

And u-boot maybe then does extlinux type boot; rather than the usual u-boot method of going straight to the linux kernel.

The SPL is used because probably at the stage the arm processor is probably only using its internal SRAM, it hasn't yet enable the external DRAM. This isn't enough for u-boot to come up in, so U-Boot SPL is used, it just just enough to get the memory up. So main u-boot can be loaded.

tinkerboard set up is strange, in that after SPL it goes back to Boot Rom, and that seems to be what goes back out to u-boot proper. Also there is the ~32 bytes of code at 0x8000, and the modified header on the SPL. What these are for isn't clear, but are kind of mentioned on the rockchip page you posed to originally.

I haven't been able to find what the 32 bytes to, e.g. source code. Guess we could disassemble it to mnemonics, just to see what it does, can't see what else to do.

There is some code u-boot source tools directory (rkimage) that looks like it may do the SPL header.

As the tinker u-boot config is so minimal, I suspect its a set up that saves it variables to flash, so will need to find where that is, and set up. That or enable uboot.src - which is the new method.

$this->bbcode_second_pass_quote('summers', 't')he tinker config doesn't have it

[summers]

Yes on free time this evening (if any exists) I'll try and work out how the u-boot (proper) evn variables are done, there must be something that tells u-boot what to do, and its almost certainly standard u-boot. Hence we should be able to access it. That will give much of the story (well, if its env varaibles, they are set up as a tree structure, and need unwrapping into a story ...)

Oh yes, on the UART that I can see, from checking looks like messages come out on:

Pin 32 is TX (so attach the RX cable to it)
Pin 33 is RX (so attach the TX cable to it)
Pin 34 is a nearby Earth, so attach earth to it

Think the same UART is used in u-boot and kernel, I'll check that later ...

[TheSaint]

The UART are 4, so the ttyS2 is available unless to disable the PWM2 which takes the hardware priority. That is done with hw_intf.conf in the boot partition.
$this->bbcode_second_pass_code('', '$ cat /boot/hw_intf.conf

#Hardware Interface Config

intf:spi0=off
intf:uart2=on
intf:uart3=on
intf:uart4=on
intf:pcm_i2s=on
intf:i2c1=on
intf:i2c4=on
intf:spi2=on
intf:pwm2=on
intf:pwm3=on
intf:uart1=on

#DTS Overlay Config
# 1. check the name.dtbo in /boot/overlays
# 2. add intf:dtoverlay=name as below

#intf:dtoverlay=i2c')
For example, mine is wrong, because cannot stay pwm2 and uart2 on. The pwm2 will be chosen.
I've tried some arrangement with my USB-TTL adapter, but it isn't workable, the RX don't see 3.3 Volts level. Anyway I think by after tomorrow I'll receive the new one.