[Solved] Asus TB S

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

Re: Asus TB S

Postby summers » Fri Aug 10, 2018 1:28 pm

Yes "dmesg" will give the kernel messages that starts with "[time_stamp]", and the console when attached should give identically the same messages.

So we are looking for the messages before them, and that probably where you have to select the disto/extlinux options for which you want to boot.

Oh yes - I tried disassembling the idbloader.img - machine said it didn't look like arm code. Will try again this evening. This makes me worry that its a signature for the block at 0x8800, e.g the u-boot spl. If so its a hassle - and unless we can regenerate it for a new spl- we are stuck with the one in TinkerOS. I'll fiddle some more this evening.
summers
 
Posts: 537
Joined: Sat Sep 06, 2014 12:56 pm

Re: Asus TB S

Postby TheSaint » Sat Aug 11, 2018 2:28 pm

I've noted this one and re-read the thread from post #1. I think I might compile some experiment :)
FYi the device tree is like this
Code: Select all
$ ls /proc/device-tree   
'#address-cells'                 opp_table0
'#size-cells'                    oscillator
 __local_fixups__                pinctrl
 __symbols__                     power-management@ff730000
 aliases                         pwm@ff680000
 amba                            pwm@ff680010
 arm-pmu                         pwm@ff680020
 bus_intmem@ff700000             pwm@ff680030
 chosen                          qos@ffaa0000
 cif@ff950000                    qos@ffaa0080
 cif_isp@ff910000                qos@ffad0000
 clock-controller@ff760000       qos@ffad0100
 compatible                      qos@ffad0180
 copyright                       qos@ffad0400
 cpus                            qos@ffad0480
 display-subsystem               qos@ffad0500
 dmc@ff610000                    qos@ffad0800
 dp@ff970000                     qos@ffad0880
 dsi@ff960000                    qos@ffad0900
 dsi@ff964000                    qos@ffae0000
 dwmmc@ff0c0000                  qos@ffaf0000
 dwmmc@ff0d0000                  qos@ffaf0080
 dwmmc@ff0e0000                  reserved-memory
 dwmmc@ff0f0000                  rga@ff920000
 efuse@ffb40000                  rk3288-gpiomem
 ethernet@ff290000               rockchip-suspend
 external-gmac-clock             saradc@ff100000
 fixedregulator_3v3              sdio-pwrseq
 flash-regulator                 sdmmc-regulator
 gpio-keys                       serial@ff180000
 gpio-leds                       serial@ff190000
 gpu@ffa30000                    serial@ff1b0000
 hdmi@ff980000                   serial@ff1c0000
 hevc-service@ff9c0000           serial@ff690000
 i2c@ff140000                    sound-ext-card
 i2c@ff150000                    sound-simple-card
 i2c@ff160000                    sound@ff8b0000
 i2c@ff170000                    spi@ff110000
 i2c@ff650000                    spi@ff120000
 i2c@ff660000                    spi@ff130000
 i2s@ff890000                    sram@ff720000
 iep@ff90000                     syscon@ff740000
 interrupt-controller@ffc01000   syscon@ff770000
 interrupt-parent                syscon@ffac0000
 io-domains                      system-id
 iommu@ff900800                  testcase-data
 iommu@ff914000                  thermal-zones
 iommu@ff930300                  timer
 iommu@ff940300                  timer@ff6b0000
 iommu@ff9a0800                  tsadc@ff280000
 iommu@ff9c0440                  usb@ff500000
 ion                             usb@ff520000
 isp@ff910000                    usb@ff540000
 lvds@ff96c000                   usb@ff580000
 memory                          usb@ff5c0000
 model                           vdd_log
 name                            video-codec@ff9a0000
 nocp-core@ffac0400              vop@ff930000
 nocp-gpu@ffac0800               vop@ff940000
 nocp-peri@ffac0c00              vpu-service@ff9a0000
 nocp-vio0@ffac1400              vsys-regulator
 nocp-vio1@ffac1800              watchdog@ff800000
 nocp-vio2@ffac1c00              wireless-bluetooth
 nocp-vpu@ffac1000               wireless-wlan
 opp-table1

There's one extra USB, that might be the BT device.
TheSaint
 
Posts: 243
Joined: Mon Jul 23, 2018 7:57 am

Re: Asus TB S

Postby summers » Sat Aug 11, 2018 3:33 pm

Boy thats one busy device tree, on my machines most stuff is one level down. What you can use the /proc/device-tree for is to see what was enabled on boot. e.g. for me (odroid-c2):
Code: Select all
cat /proc/device-tree/soc/ethernet\@c9410000/status
okay

So you can see that the ethernet is enabled. And thats why it shows up on "ip a". Now for you it was trying to find the wireless, but that problem we have solved.

What it would be useful for you, is to check that the pwm are disabled. So you need a command like:
Code: Select all
cat /proc/device-tree/pwm*/status

And hopefully you'll see that most (if not all) are disabled - and so that removes the conflict with tty2.

Oh yes, I made a break through on the boot set up in tinkerOS.

Partition 0x40 is just a packaged u-boot SPL. So we can generate that with:
Code: Select all
./tools/mkimage -n rk3288 -T rksd -d spl/u-boot-spl.bin idbspl.img

This is from your first link http://opensource.rock-chips.com/wiki_Boot_option. It also means we can be reasonably sure that we are doing the boot process, shown in the right hand side of the diagram, e.g. the totally open boot process.

The main u-boot I haven't yet totally figured out - but it may well just be a raw u-boot.bin (or rather that may work).

Its a wet afternoon here, so I'm just modding the none functional rk3288 set up for u-boot, so it will by default have some reasonable environment variables. Then I'll do a arch image for you, that maybe has half a chance of booting.
summers
 
Posts: 537
Joined: Sat Sep 06, 2014 12:56 pm

Re: Asus TB S

Postby summers » Sun Aug 12, 2018 8:23 pm

OK, I've tried doing an arch image as close to TinkerOS as possible on:

http://davidjohnsummers.uk/ArmArchVeyron.img.xz

After uncompressing, just write the raw img file to the sd card.

It has a spl @0x40 - where that is u-boot spl in rk package
Code: Select all
dd conv=notrunc bs=512 seek=64 of=ArmArchVeyron.img if=idbspl.img

At 0x84 is the main uboot, just the image file:
Code: Select all
dd conv=notrunc bs=512 seek=132 of=ArmArchVeyron.img if=u-boot.bin


I've given you the lastest 2018-07 uboot, I've configured it to be as close to the beagle set up, but have no idea if it will work.

Arch is the latest veyron one, I've added a kernel, and also given you a boot.scr as hopefully u-boot will use that (have no idea how to configure that !)

All output should come out on uart2, hopefully all pwm disabled ...

Would be good if you could try it, then if it works look at doing clearer instructions ...
summers
 
Posts: 537
Joined: Sat Sep 06, 2014 12:56 pm

Re: Asus TB S

Postby TheSaint » Mon Aug 13, 2018 4:20 pm

summers wrote:Would be good if you could try it

I can't refuse it ;) It is the least I must do, for a benefactor like you :).
For me I might take one more year to understand how to do these step as you done. It's really a very new ground to discover.

Yesterday I tried to compile the 8723bs module, to make it STA and AP, but I faced something bad in the built. One simlink to a inexistent directory :( .
I'll see whether this new kernel has better chances.
Trying it out.

EDIT
It doesn't show anything :roll:
I might have done it wrongly, I just dd the whole image to the SD card. Then I wondered that there's no space left for the partition.
I saw that there's an option to try the installation by qemu. Aren't you aware of ?
TheSaint
 
Posts: 243
Joined: Mon Jul 23, 2018 7:57 am

Re: Asus TB S

Postby summers » Mon Aug 13, 2018 6:10 pm

Well the image was reasonably small - just enough to fit the arch image in.

So if you saw nothing, was this on the screen, or on uart2 ?

If it barfed early good idea to know where - and thats what we get on uart 2.
summers
 
Posts: 537
Joined: Sat Sep 06, 2014 12:56 pm

Re: Asus TB S

Postby TheSaint » Mon Aug 13, 2018 6:28 pm

OK. sorry I forgot to mention it. I plugged on UART2, as it was previously written. But if no kernel configuration I doubt I'll see something from there.
I didn't try to see if it showing on the screen. I'll try it tomorrow.
Have you modified for the UART2 to work on the ttyS2?
Because I've noted the UART2 only works if there's a configured condition. Perhaps in the early u-boot or kernel stage.
I also compiled rkdeveloptool (usually they keep the file for a limited time, hurry), but it may be difficult to use without the hardware. Unless can use it on an image.
TheSaint
 
Posts: 243
Joined: Mon Jul 23, 2018 7:57 am

Re: Asus TB S

Postby summers » Mon Aug 13, 2018 8:19 pm

The main output would have come on tty2/uart2, I expect the screen to only kick in when the kernel comes up a long way.

So if we got nothing at all, its quiet annoying. Both u-boot and the device tree were set up for uart2. So if nothing suggests that even u-boot spl wasn't coming up. This means we didn't even start. All I can think is it was a GPT set up, which doesn't make sense, the TinkerOS was msdos.

How are you calling up the uart? need something like:
Code: Select all
screen /dev/ttyUSB0 115200
summers
 
Posts: 537
Joined: Sat Sep 06, 2014 12:56 pm

Re: Asus TB S

Postby TheSaint » Tue Aug 14, 2018 8:47 am

Today I tried with the monitor plugged into HDMI, but same case, no joy :(
summers wrote:How are you calling up the uart? need something like:

Well, how am I supposed to do that in a blank screen ?

The running conditions, with Tinker kernel, the setting is taken from hw_intf.conf. So how this works it's rather a discovery.
I taught that using the rkdeveloptool we may build the way to boot into a full fledged extlinux or grub, then the rest it would be a simpler manner to use and maintain.
So, perhaps it should go for GPT and ESP, then from ESP the rest might be an ordinary administration. Even MBR can suffice. All it's needed, first, a running kernel. Once we'll see the kernel complaining, we may look to give something more to chew ;)

Even lesser would be enough. I saw that u-boot has a shell command line, so what about to get that up ?

From my research I found something to have a note. Except for the kernel, there are other sources to use for the boot process. I presume that is better than what is given from TinkerBoard web site.
Also this helps to get clearer ideas, but is rather leading to install a debian box.
TheSaint
 
Posts: 243
Joined: Mon Jul 23, 2018 7:57 am

Re: Asus TB S

Postby summers » Tue Aug 14, 2018 9:40 am

TheSaint wrote:Today I tried with the monitor plugged into HDMI, but same case, no joy :(
summers wrote:How are you calling up the uart? need something like:
Code: Select all
screen /dev/ttyUSB0 115200

Well, how am I supposed to do that in a blank screen ?

Usually with a uart connection, you plug the TB S uart into a uart to USB cable. The usb cable you plug into a second computer. On the second computer the cable is recognized, and comes up as something like /dev/ttyUSB0 (names vary, used to get /ttyACM0).

So on the second computer you start monitoring the UART before you switch on the TBS. That way you capture all output when you switch on the TB S.

Also you can type in the second computer connection, e.g. if you want to access the u-boot command line ...

:)
summers
 
Posts: 537
Joined: Sat Sep 06, 2014 12:56 pm

PreviousNext

Return to Community Supported

Who is online

Users browsing this forum: No registered users and 0 guests