[Solved] Asus TB S

[summers]

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.

[TheSaint]

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$this->bbcode_second_pass_code('', '$ 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.

[summers]

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):
$this->bbcode_second_pass_code('', '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:
$this->bbcode_second_pass_code('', '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:
$this->bbcode_second_pass_code('', './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]

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
$this->bbcode_second_pass_code('', 'dd conv=notrunc bs=512 seek=64 of=ArmArchVeyron.img if=idbspl.img')
At 0x84 is the main uboot, just the image file:
$this->bbcode_second_pass_code('', '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 ...

[TheSaint]

$this->bbcode_second_pass_quote('summers', 'W')ould be good if you could try it

[summers]

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.

[TheSaint]

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.

[summers]

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:
$this->bbcode_second_pass_code('', 'screen /dev/ttyUSB0 115200')

[TheSaint]

Today I tried with the monitor plugged into HDMI, but same case, no joy
$this->bbcode_second_pass_quote('summers', 'H')ow are you calling up the uart? need something like:

$this->bbcode_second_pass_quote('TheSaint', 'T')oday I tried with the monitor plugged into HDMI, but same case, no joy
$this->bbcode_second_pass_quote('summers', 'H')ow are you calling up the uart? need something like:
$this->bbcode_second_pass_code('', 'screen /dev/ttyUSB0 115200')