[Solved] Asus TB S

[TheSaint]

I started to think that the solution to get the TB S mainlined is only to fix on the device-tree. So that should drive the kernel within its standard compilation.
The only point that I still need to learn is how this can be done. I appreciated very much the explanations and I learned some new bits on this platform, But I still miss to know how to arrange a device-tree file.

[summers]

Yes! The device tree is the main thing that needs set up for new hardware, and the TB S is new hardware.

The device tree describes hardware, so if the description in the device tree is perfect, then the kernel knows what it has to do. The drivers in linux, are pretty much slam up to date - they know the chips they talk to, so when they know how to talk to the chips they work well.

The flip side, these days, is when there are problems, its most usually in the device tree. The linux kernel driver tend to be good, often coming from the manufacture. It you look at changes going into the kernel it is dominated by the major companies, e.g. for arm linarno is a major contributor, and that is practically a consortium of major arm developers.

Its why I've been talking about the device tree from the start of the thread. Have to say, I'm not an expert in device trees. I'm really not much more than a user - in that many of my arm projects have needed device tree modifications. Being a user, I know simple ways round the device tree; so can have a hissing fit when I see that the TB schematic doesn't show the sd card wiring - and if the CD is connected. But also means I don't know the details, writing a device tree from scratch and I'd get it wrong - that I know.

Anyway, hopefully this weekend, I submit the patches to support the TB S. At least basic, eMMC, and hopefully wifi - but thats less clear. It means rolling things the kernel way, so am busy setting a a git clone of the rockchip linux kernel - just so I can patch against it. Then the battle starts with getting it mainlined - wether I be successful or not I don't know. I am hopeful through on eMMC - as its a simple obvious change; wifi still scares me - whilst I have patches, the patches do things unexpected - so for me at least it means raised eyebrows ...

[TheSaint]

Finally I got to this point too. Sorry I got to learn newer things along this experiments.
The I started to think why there are three different dtf for this board. One is u-boot's rk3288-tinker.dts +rk3288-tinker.dtsi, another is kernel's rk3288-tinker.dts and the last is rk3288-miniarm. All of these concurring to do something which should make tinker board work. Less probable that would work for the added eMMC model.

So I thought there's a difference that is given by the age of every one of them. Anyway no one is good enough to give us the chance to start a kernel. I think that if the dft is good it won't make any difference to start any kernel.

I saw that at github/u-boot they just update rk3288-tinker.dtsi, few days back.

I don't know yet what exactly these dtf are doing, I'm studying them by comparison and see if the declaration are congruent.
I wrote to TB web site and I hope some volunteer will come over.

Today I tried another u-boot image, without patches because I thought the configuration is given for good. But I was wrong and it failed.

EDIT
I can't deny that the patches are necessary and specific for TB S, so u-boot drive up to the kernel as expected. Furthermore, most of the patches are Mr Jamess Hung (Asus engineer).
I set up with the latest u-boot commit. I saw a little difference

Code: Select all

U-Boot SPL 2018.09-rc2-00160-gc3c19c2743-dirty (Sep 02 2018 - 11:54:38 +0800)
Returning to boot ROM...


U-Boot 2018.09-rc2-00160-gc3c19c2743-dirty (Sep 02 2018 - 11:54:38 +0800)

DRAM:  2 GiB
PC event = 0x0
usb_current_limit_ctrl: unlock_current = 0
MMC:   dwmmc@ff0c0000: 1, dwmmc@ff0f0000: 0
Loading Environment from MMC... *** Warning - bad CRC, using default environment

In:    serial
Out:   serial
Err:   serial

The (fail -5) is gone and seems to find two mmc locations. But there was only eMMC during the boot. The polling for the SD card still flooding the kernel log in dmseg. It must have a SD card to calm it down.

So, the only perspective for TB S is this kind of u-boot, which can't be generalized, then remain specific for this board, as much as many other SBC.

The rest might go into device-tree file to guide the kernel in a correct manner. I feel that there's a concern in the way to handle the iommu. There's a error

Code: Select all

[    3.642859] rk_iommu ff930300.iommu: Failed to get clk 'aclk': -2
[    3.643686] rk_iommu ff940300.iommu: Failed to get clk 'aclk': -2
Warning: /lib/modules/4.18.5-1-ARCH/modules.devname not found - ignoring
starting version 239
TB-MM-root: Superblock last mount time is in the future.
        (by less than a day, probably due to the hardware clock being incorrectly set)
TB-MM-root: Superblock last write time is in the future.
        (by less than a day, probably due to the hardware clock being incorrectly set)
TB-MM-root: clean, 96127/262144 files, 724106/1048576 blocks
[    6.294101] rk_iommu ff930300.iommu: Error during raw reset. MMU_DTE_ADDR is not functioning
[    6.348387] rk_iommu ff940300.iommu: Error during raw reset. MMU_DTE_ADDR is not functioning

I've also tried LXDE and it is there. Just with the plain framebuffer using mesa

[TheSaint]

So it seems most of things are working. But I got no USB detection, which I presume to be related to the dft. I'd like to know better about that.

[summers]

Hmm - USB devices don't show up.

Reason device tree is so good for arms, is that the pin out on arms can be wired up many ways - and you only get to know which, by how its described.

Now usb, and that is usually on dedicated lines, and in the case of arm usually on the arm, the usb controller is part of the design. This is the case with the rk3288.

So usually expect that the kernel on booting would detect the usb, just through probing the extent of processor capabilities.

What does

Code: Select all

lsusb

show? I'd expect it to see the hubs - in which case then wonder why it doesn't work ...

And just checked. rk3288 has two usb hubs, and an otg usb. These are defined in the high level device tree rk3288.dtsi - so the chip device tree. In the tinker board device tree - all it does is enable these three - so there is no configuration needed. usb is handled by the phy set up in the linux kernel - and there seems a standard rockchip way of doing that. So bit confusing why it doesn't work ...

[TheSaint]

Code: Select all

$ lsusb
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 05e3:0610 Genesys Logic, Inc. 4-port hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 002: ID 0bda:481a Realtek Semiconductor Corp.
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
$ ls /proc/device-tree/usb\@ff*
/proc/device-tree/usb@ff500000:
clock-names  clocks  compatible  interrupts  name  phy-names  phys  reg  status

/proc/device-tree/usb@ff540000:
clock-names  compatible  interrupts  phy-names  reg
clocks       dr_mode     name        phys       status

/proc/device-tree/usb@ff580000:
clock-names  dr_mode            g-tx-fifo-size  phy-names  status
clocks       g-np-tx-fifo-size  interrupts      phys
compatible   g-rx-fifo-size     name            reg

/proc/device-tree/usb@ff5c0000:
clock-names  clocks  compatible  interrupts  name  reg  status

But if I plug a memory it won't do anything. It may be even a problem with the USB power limits.
However with linaro kernel is working

Code: Select all

$ dmesg |tail[   62.363614] usb-storage 1-1.2:1.0: USB Mass Storage device detected
[   62.371141] scsi host0: usb-storage 1-1.2:1.0
[   63.377382] scsi 0:0:0:0: Direct-Access     Kingston DataTraveler 2.0 1.00 PQ: 0 ANSI: 2
[   63.390619] sd 0:0:0:0: [sda] 31539200 512-byte logical blocks: (16.1 GB/15.0 GiB)
[   63.411091] sd 0:0:0:0: [sda] Write Protect is off
[   63.416975] sd 0:0:0:0: [sda] Mode Sense: 23 00 00 00
[   63.418309] sd 0:0:0:0: [sda] No Caching mode page found
[   63.424752] sd 0:0:0:0: [sda] Assuming drive cache: write through
[   63.694939]  sda: sda1
[   63.721504] sd 0:0:0:0: [sda] Attached SCSI removable disk

[summers]

Yes you see all the usb hubs you should. So when you plug in a device you get no errors on "dmesg" ? When you plug in a usb device with lights (leds) - do they light?

Anyway I may dig- if I get spare time, but given how little idea I have on whats going wrong - it would probably be no more academic interest ....

[TheSaint]

The Kingston memory got a LED, which blink when plugged for normal use, may be while reading. With the new ftd it doesn't do anything.
Anyway this is a little issue, for my usage may not be urgent.
There was a time that the u-boot didn't find mmc then triyng to probe the USB. This time with the UMS plugged I get this

Code: Select all

PC event = 0x0
usb_current_limit_ctrl: unlock_current = 0

I stopped the autoboot and checking

Code: Select all

=> usb start
starting USB...
USB0:   USB1:   scanning bus 0 for devices... 3 USB Device(s) found
scanning bus 1 for devices... 1 USB Device(s) found
       scanning usb for storage devices... 1 Storage Device(s) found

=> usb info
1: Hub,  USB Revision 1.10
 -  U-Boot Root Hub
 - Class: Hub
 - PacketSize: 8  Configurations: 1
 - Vendor: 0x0000  Product 0x0000 Version 0.0
   Configuration: 1
   - Interfaces: 1 Self Powered 0mA
     Interface: 0
     - Alternate Setting 0, Endpoints: 1
     - Class Hub
     - Endpoint 1 In Interrupt MaxPacket 2 Interval 255ms

2: Hub,  USB Revision 2.0
 -  USB2.0 Hub
 - Class: Hub
 - PacketSize: 64  Configurations: 1
 - Vendor: 0x05e3  Product 0x0610 Version 50.152
   Configuration: 1
   - Interfaces: 1 Self Powered Remote Wakeup 100mA
     Interface: 0
     - Alternate Setting 0, Endpoints: 1
     - Class Hub
     - Endpoint 1 In Interrupt MaxPacket 1 Interval 12ms
     - Endpoint 1 In Interrupt MaxPacket 1 Interval 12ms

3: Mass Storage,  USB Revision 2.0
 - Kingston DataTraveler 2.0 000AEB920172SK861C01001F
 - Class: (from Interface) Mass Storage
 - PacketSize: 64  Configurations: 1
 - Vendor: 0x0951  Product 0x1607 Version 2.0
   Configuration: 1
   - Interfaces: 1 Bus Powered 200mA
     Interface: 0
     - Alternate Setting 0, Endpoints: 2
     - Class Mass Storage, Transp. SCSI, Bulk only
     - Endpoint 1 In Bulk MaxPacket 512
     - Endpoint 2 Out Bulk MaxPacket 512

1: Hub,  USB Revision 1.10
 -  U-Boot Root Hub
 - Class: Hub
 - PacketSize: 8  Configurations: 1
 - Vendor: 0x0000  Product 0x0000 Version 0.0
   Configuration: 1
   - Interfaces: 1 Self Powered 0mA
     Interface: 0
     - Alternate Setting 0, Endpoints: 1
     - Class Hub
     - Endpoint 1 In Interrupt MaxPacket 2 Interval 255ms


Hence, as I can see, the u-boot doesn't fail to handle the usb. I think it might be a missing bit to pass to the kernel.

Later I'll experiment to revert the usb declarations from the rk3288-miniarm to the rk3288-tinkerS. the miniarm is the working one.

EDIT

I modified the dtf, but I did it with poor knowledge.
Then are coming some error

Code: Select all

[    4.267610] OF: /usb@ff540000: could not get #phy-cells for /qos@ffad0100
[    4.275908] OF: /usb@ff580000: could not get #phy-cells for /qos@ffad0180
[    4.285058] OF: /usb@ff500000: could not get #phy-cells for /qos@ffad0000

[summers]

Forgot to say. Rather than modifying the dts, and recompiling to a dtb, instead uboot can modify the dtb that it loads.

This we can do by modifying boot.{txt,scr}.

This is the safer way to do it - as if you get something seriously wrong, so the machine doesn't boot. Then its easy to pull the sd card, and correct boot,{txt,scr} on another machine.

The commands are in my beagle bone black threads - I'll dig them out when I get home this evening.

[TheSaint]

Thanks to remember me about it. Luckily the error is minimal, I used to make a backup rather than change the boot.scr.
Maybe I should see what are the differences that are causing that error.

Anyway I'd start a new thread. This is good as it stated the way to boot Archlinux on the TB S.