Device-tree improvements

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

Device-tree improvements

Postby TheSaint » Fri Sep 07, 2018 2:14 pm

Hello forum,
after a quiet troubled start with my Tinker Board S, I'm looking for a bit improvements because I faced the USB subsystem has a flaw.
I tried this device-treee file, but there are some error coming and any attempt to discover an UMS plugged in is vain.
I also suspect that included into that subsystem is working the WiFi connection to the Realtek chip. But I didn't find any flaw.
TheSaint
 
Posts: 346
Joined: Mon Jul 23, 2018 7:57 am

Re: Device-tree improvements

Postby TheSaint » Sat Sep 08, 2018 12:47 am

@summers
Refer this post
Applied the changes but it still not working :(
$this->bbcode_second_pass_code('', 'ls /proc/device-tree
'#address-cells' hdmi@ff980000 pwm@ff680000 serial@ff1b0000
'#size-cells' i2c@ff140000 pwm@ff680010 serial@ff1c0000
aliases i2c@ff150000 pwm@ff680020 serial@ff690000
amba i2c@ff160000 pwm@ff680030 sound
arm-pmu i2c@ff170000 qos@ffaa0000 sound@ff88b0000
bus_intmem@ff700000 i2c@ff650000 qos@ffaa0080 spi@ff110000
chosen i2c@ff660000 qos@ffad0000 spi@ff120000
clock-controller@ff760000 i2s@ff890000 qos@ffad0100 spi@ff130000
compatible interrupt-controller@ffc01000 qos@ffad0180 sram@ff720000
cpus interrupt-parent qos@ffad0400 syscon@ff740000
cypto-controller@ff8a0000 io-domains qos@ffad0480 syscon@ff770000
display-subsystem iommu@ff900800 qos@ffad0500 thermal-zones
dp@ff970000 iommu@ff914000 qos@ffad0800 timer
dwmmc@ff0c0000 iommu@ff930300 qos@ffad0880 timer@ff810000
dwmmc@ff0d0000 iommu@ff940300 qos@ffad0900 tsadc@ff280000
dwmmc@ff0e0000 iommu@ff9a0800 qos@ffae0000 usb@ff500000
dwmmc@ff0f0000 iommu@ff9c0440 qos@ffaf0000 usb@ff540000
efuse@ffb40000 lvds@ff96c000 qos@ffaf0080 usb@ff580000
ethernet@ff290000 memory reserved-memory usb@ff5c0000
external-gmac-clock mipi@ff960000 rga@ff920000 vop@ff930000
flash-regulator model saradc@ff100000 vop@ff940000
gpio-keys name sdio-pwrseq vsys-regulator
gpio-leds oscillator sdmmc-regulator watchdog@ff800000
gpu-opp-table pinctrl serial@ff180000 wireless-bluetooth
gpu@ffa30000 power-management@ff730000 serial@ff190000 wireless-wlan')

Mhmm, even bluetooth is not found$this->bbcode_second_pass_code('', ' sudo rfkill list
0: phy0: Wireless LAN
Soft blocked: no
Hard blocked: no
')
TheSaint
 
Posts: 346
Joined: Mon Jul 23, 2018 7:57 am

Re: Device-tree improvements

Postby summers » Sat Sep 08, 2018 1:18 pm

Probably worth checking in $this->bbcode_second_pass_code('', 'ls /proc/device-tree/usb@ff500000') just to check that $this->bbcode_second_pass_code('', 'no-relinquish-port') has appeared.

Anyway gives the basics of how to modify the device tree from uboot - you may need the occasional $this->bbcode_second_pass_code('', 'fdt resize') if you are making big changes. So for example you may want to try:
$this->bbcode_second_pass_code('', 'fdt set /dwmmc@ff0c0000 broken-cd')
to see if it helps with the sd card errors when no card is there. Another independent option:
$this->bbcode_second_pass_code('', 'fdt set /dwmmc@ff0c0000 cd-gpios <&gpio 69 0>') where that gpio address is made - so need to work out how to give the nominal sdmmc cd pin on the rk3288 ...
summers
 
Posts: 984
Joined: Sat Sep 06, 2014 12:56 pm

Re: Device-tree improvements

Postby TheSaint » Sat Sep 08, 2018 5:56 pm

$this->bbcode_second_pass_quote('summers', 'P')robably worth checking in /proc

$this->bbcode_second_pass_code('', 'ls /proc/device-tree/usb@ff500000
clock-names clocks compatible interrupts name phy-names phys reg status')
Even grepping in that directory nothing found.
$this->bbcode_second_pass_quote('summers', ' ')you may need the occasional


Should I write these commands to the boot.scr ?
It looks like a wizardry :D. I should find a good recipe :)
TheSaint
 
Posts: 346
Joined: Mon Jul 23, 2018 7:57 am

Re: Device-tree improvements

Postby summers » Sun Sep 09, 2018 1:30 pm

Pity commands didn't create "no-relinquish-port". Guess you ran "./mkscr" after changing boot.txt

The sdmmc commands are what the documentation gives for controlling the card detect (cd) on an sd card. the rk3288 has a collection for card detect "SDMMC0_DECTN ball AH5", but we can't tell from the schematic if it is wired.

Now with nothing else setting it, the device tree documentation says the driver should do card detect using the chip native functionally - so what should happen is it automatically uses ball AH5. Now in your case the CD isn't working.

So hence look at the other device tree settings, and that was the commands. Either to do cd via polling, or to say its a gpio pin thats connected, which we could them hope to point to ball ah5. Alas the gpio info given, contains an &gpio - which is usually a reference to something else in the device tree, but I think removed in the blob - so no clear if we can use in uboot - and the address, and control status, won't be right ....

Oh yes - the "fdt resize" is for when you make big changes to the device tree. u-boot puts it in a bit of memory that is a multiple of 4kB iirc. So there is usuallly a bit of space for extra commands. Anyway if you are going to cross a 4k boundary - you need to do a resize first - so the device tree has room. I've only had to use it with overlays - which can easily be several k long ...
summers
 
Posts: 984
Joined: Sat Sep 06, 2014 12:56 pm

Re: Device-tree improvements

Postby TheSaint » Mon Sep 10, 2018 6:26 am

$this->bbcode_second_pass_quote('summers', 'G')uess you ran "./mkscr" after changing boot.txt

You might suspect it, but I did it :D
Anyway the card detection is working with the kernel. Just test it that the reading and udev find the SD card upon insertion.
Haven't you seen that linaro method using rk3288-miniarm and overlays?
So I will inspect what is the linaro's u-boot behavior. Probably they fixed the hardware by including the overlays.
TheSaint
 
Posts: 346
Joined: Mon Jul 23, 2018 7:57 am
Top

Re: Device-tree improvements

Postby summers » Mon Sep 10, 2018 9:24 am

$this->bbcode_second_pass_quote('', 'Y')ou might suspect it, but I did it :D
Always worth checking ;)

So card detect is working, but when booting from eMMC and no sd card you still get repeated errors on the sd card? Seems very odd if its detecting that there is no card there.

Anyway at least give you the tools to play with, take care when modifying the device tree - recall that it is really just meant to be an accurate description of hardware ...
summers
 
Posts: 984
Joined: Sat Sep 06, 2014 12:56 pm
Top

Re: Device-tree improvements

Postby TheSaint » Mon Sep 10, 2018 12:39 pm

You're right.
I think I will diminish my efforts on the matter. Basically the system is up and running. For these cases I'll study to add a result.
TheSaint
 
Posts: 346
Joined: Mon Jul 23, 2018 7:57 am

Re: Device-tree improvements

Postby TheSaint » Tue Sep 11, 2018 10:44 am

Today a brand new kernel has come.
I tried to test different dtb.
Then I found that the rk3288-tinker.dtb can boot the TB S. Still have the annoyance regarding the card detection and UMS subsystem is missing. Anyway the WiFi got recognized and working. Probably there have been some adjustment on the kernel.
I don't know whether the rk3288-tinker.dtb is new or one I putted before.
I also tried the rk3288-miniarm, but is not going that far. There are a lot of problems regarding the HDMI$this->bbcode_second_pass_code('', '[ 31.070254] rockchip-drm display-subsystem: failed to bind ff960000.dsi (ops dw_mipi_dsi_ops [rockchipdrm]): -517
[ 31.217686] rockchip-drm display-subsystem: master bind failed: -517
[ 31.235235] rockchip-drm display-subsystem: bound ff930000.vop (ops vop_component_ops [rockchipdrm])
[ 31.247847] rockchip-drm display-subsystem: bound ff940000.vop (ops vop_component_ops [rockchipdrm])
[ 31.258375] dwhdmi-rockchip ff980000.hdmi: Detected HDMI TX controller v2.00a with HDCP (DWC MHL PHY)
[ 31.269432] dwhdmi-rockchip ff980000.hdmi: registered DesignWare HDMI I2C bus driver
[ 31.281261] Registered IR keymap rc-cec
[ 31.285823] rc rc0: RC for dw_hdmi as /devices/platform/ff980000.hdmi/rc/rc0
[ 31.294118] input: RC for dw_hdmi as /devices/platform/ff980000.hdmi/rc/rc0/input78
[ 31.303357] rockchip-drm display-subsystem: bound ff980000.hdmi (ops dw_hdmi_rockchip_ops [rockchipdrm])
[ 31.314681] rockchip-drm display-subsystem: failed to bind ff960000.dsi (ops dw_mipi_dsi_ops [rockchipdrm]): -517')
I'll keep looking to the differences (rk3288-miniarm <> rk3288-tinker) and see what can be merged.
TheSaint
 
Posts: 346
Joined: Mon Jul 23, 2018 7:57 am

Re: Device-tree improvements

Postby summers » Sun Sep 16, 2018 5:33 pm

@TheSaint

Favour to ask, can you try out the device tree blob: http://davidjohnsummers.uk/rk3288-tinker-s.dtb.

This is the one that my second go at getting changes to the main kernel to enable the tinker board S.

It *should* be identical to the last one sent - but its constructed from a set of patches, and a refactoring of how the kernel does tinker devices - so the code is very different (but its easier to follow changes).

I'll be submitting it to the various people, in next half hour - just because if I don't do it today, won't be done till next weekend (have a ESA/NASA/JAXA interagency meeting on tuesday - which will be political. And a proposal to go in on friday ...) Anyway it would be good to get more comments back from the kernel people. This change may not make it in, but it will be closer than the first one ...
summers
 
Posts: 984
Joined: Sat Sep 06, 2014 12:56 pm

Next

Return to Community Supported

Who is online

Users browsing this forum: No registered users and 5 guests