<topi`>
what's needed for DMA? I'd think everything for DMA is already contained in rk3288.dtsi ...
<topi`>
rtp: yes, and it is empty.
<topi`>
working with device-trees is not easy... because I don't really understand should something come as a "root" node or a subnode somewhere else.
<topi`>
I guess the &i2c0 needs to sit at the top level
<topi`>
why does it need the ampersand?
<rtp>
yes, you need &i2c0 and not i2c0. if you don't know how to write something, just look at existing dts. Since you have a 3288, look at the arch/arm/boot/dts/rk3288-* files in the kernel tree
<robmur01>
that's the syntax for referencing a previously-defined node by label
camus1 has joined #linux-rockchip
kaspter has quit [Ping timeout: 258 seconds]
camus1 is now known as kaspter
chewitt has joined #linux-rockchip
stikonas has joined #linux-rockchip
<topi`>
yeah so the i2c0 gets originally defined in rk3288.dtsi ?
<topi`>
I'll try to learn it by heart
warpme_ has joined #linux-rockchip
<topi`>
i2c0: i2c@ff650000 {
<topi`>
compatible = "rockchip,rk3288-i2c";
<topi`>
<topi`>
yeah, there it is. status=disabled, so I just need to set &i2c0 with status = Okay
<topi`>
also, "lsusb" shows nothing, so I guess I've some work left to do here
<topi`>
usb bus is powered, I see the led fire up on the usb stick
<topi`>
I guess I need to hire some guy from free-electrons to craft me a good .dts
<topi`>
very few rk3288 boards seem to have the rk808 regulator. Is this a significant difference?
<topi`>
also none seem to have the TI DP83867 eth phy.
<rtp>
as said, look at existing dts/dtsi files. For the ti phy, look at the arch/arm/boot/dts/rk3288-phycore-som.dtsi. It seems to have it
<topi`>
thanks
<topi`>
hmm. I noticed this kernel is from May, so it's 5.7 series. Too old perhaps?
<topi`>
phy-supply = <&vdd_eth_2v5>;
<topi`>
it has a very odd voltage in phy-supply
<rtp>
you can finish writing your dts with 5.7 and switch to newer later
<rtp>
you may have to adapt to your needs the dts. Just don't cut&paste blindly things but try understanding how things are working
<topi`>
yeah thats the problem.
<topi`>
I wonder why, in pinctrl, the gmac {} node defines phy_rst ...shouldn't this belong to the PHY part?
<topi`>
or is this just a way to say what the gmac driver should do when it wants to reset the PHY?
<topi`>
I guess I need the schematics for this board. to see which gpio goes to which pin...
<rtp>
I've never looked at rk gmac so I can't comment about phy_rst, sorry
<topi`>
I have a 3.10 android kernel for this board, which seems to work, and it contains a DT.
<rtp>
and it's no documented in Documentation/devicetree/bindings/net/rockchip-dwmac.txt
<topi`>
but it seems to be organised way differently than any DTs in the 5.x kernels.
<rtp>
in theory, it should not, but in practice, it may. at least, you'll get hw infos to write the dts from it
<topi`>
yeah, there needs to be the info about which gpio to use for phy reset.
<robmur01>
pinctrl organisation isn't hugely critical - as long as _something_ claims the pins that matter then stuff generally works
<topi`>
I guess my dts is buggy because USB doesn't seem to work. Might this be because of a regulator not active?
<topi`>
I thought usb would work out-of-the-box because it's deeply integrated in the RK3288 soc and you can't really screw that up
<robmur01>
historically most dwmac users relied on auto-detecting the phy anyway, and the 2its reset properties did actually belong to
<topi`>
and USB doesn't need magnetics like ethernet
<robmur01>
[ er, that wasn't my right shift key... ]
<robmur01>
...and the old "snps,phy*" reset properties did belong to the MAC node itself
<topi`>
I'm trying to learn all this DT stuff. Back then when I actually worked on the kernel, on OMAP3, board config files were all we had.
<topi`>
I see these "snps*" nodes everywhere, are they deprecated?
<rtp>
topi`: not active regulator or some usb node not enabled. Have a look at /proc/device-tree on the running system
<topi`>
so does this mean I have 4 usb hubs declared?
<robmur01>
upstream I think it's now preferred to explicitly describe the phy and use generic reset properties, but that's a relatively recent move
<topi`>
ah! all these usb nodes have the "status" entry say "disabled"
<robmur01>
declared yes, but are they enabled? Check their "status" properties
<topi`>
how to enable them from bash?
<topi`>
I'd rather muck around the device tree in a live system than try to run "make dtbs" and then transform those files back and forth the SD card...
<rtp>
iirc, you can't. you have to add the needed bits in the dts (eg &<node> { status = "okay"' };
<rtp>
<node> { status = "okay"; |;
<rtp>
rahh
<rtp>
<node> { status = "okay"; };
<rtp>
&<node> { status = "okay"; };
<robmur01>
I don't think that's possible even with overlay hacks, since no devices would have been created by of_platform_populate() at boot
<topi`>
so I can just define one single parameter inside the node and it just modifies that one?
<topi`>
hmm... it seems I'm lacking the nodes for usb_host and usb_otg
<topi`>
can I just copy those over from rk3288-phycore-rdk.dts ?
<topi`>
&usb_host0_ehci {
<topi`>
status = "okay";
<topi`>
};
<rtp>
yeah, adding theses 3 lines may possibly be enough to get some usb
<topi`>
[ 3.527207] usb 1-1: new high-speed USB device number 2 using dwc2
<topi`>
WOW
<topi`>
thank you guys! now I can setup a nfsroot using a usb-ethernet-adapter
<topi`>
rtp: yes, those lines really did the trick. This actually shows the power of DT
<topi`>
I remember back in 2.6 kernel times, when going from OMAP2 to OMAP3, there was a huge amount of copypaste involved to get some working board files
<topi`>
I've been writing python for way too many years... time for a change.
<topi`>
reset-gpio in the old DT for &gmac should now be replaced with pinctrl-0 = <&rgmii_pins &phy_rst>; right?
<topi`>
oh, reset-gpio is there, but it is snps,reset-gpio
<topi`>
gmac_v18sel = <1>;//rgmii 1.8v/3.3v voltage
<topi`>
is this something that the gmac driver is looking for using the of_get_property() calls?
<topi`>
yes, it seems, in stmmac_platform.c
<topi`>
it seems to be one of the platform quirks, because this value is being saved in bsp_priv struct
<robmur01>
hmm, on Rockchip platforms I/O voltage selection is normally handled by the rockchip-iodomain driver knowing about the relevant regulators
<topi`>
this 3.10 kernel contains some code that pokes into registers, probably enabling that 1.8V
<topi`>
grf_writel(val, RK3288_GRF_IO_VSEL);
<topi`>
it enables some bits on this register. Lets see what that reg controls.
<topi`>
I found an answer, but it was in Chinese, in t-firefly.com
<robmur01>
yup, that's the stuff that should be described for the I/O domain driver
<robmur01>
according to the schematic it looks like the relevant domain for ethernet is "flash1-supply", confusingly
<topi`>
&io_domains {
<topi`>
I guess I need this definition
<topi`>
flash1-supply = <&vdd_misc_1v8>;
<topi`>
(this is from the rk3288-phycore dts file)
<topi`>
it's using rk818 whereas this board has RK808
<robmur01>
well, it really just needs to point at *something* that represents the voltage being used for the RGMII link (which of course might not necessarily be equal to the phy's main power supply)
<topi`>
I notice the rk818 has different supply names than rk808
<topi`>
I'll try to see how they are defined in the 3.10 kernel
<topi`>
&flash1_vdd_domain{
<topi`>
regulator-name = "vcc_flash";
<topi`>
};
<topi`>
it has this kind of definition... this seems to predate the io_domains { } node
<robmur01>
the SoC interface is only the D+/D- pins, it's still the board's job to provide vbus somehow ;)
<topi`>
yeah
<topi`>
but it seems that the old android kernel is trying to do the same things as this 5.x phycore DT entry, they both provide 1.8 volts for the PHY
<robmur01>
[ er, wrong message again... today I not type good :( ]
<topi`>
I copied lots of stuff over from the 3288_evb_rk808
<topi`>
but there the ethernet PHY is different
<robmur01>
yeah, with the Realtek phys I think the I/O voltage is usually actually supplied by the phy itself, but there's little point in intricately describing the phy's internal LDOs as regulators in DT when you can just wang it onto something else nearby that matches
<topi`>
I did not cut paste it.. It seems I wrote "address-cells" when it should have been "#address-cells"
<topi`>
[ 3.088096] vcc_tp: Bringing 1800000uV into 3300000-3300000uV
<topi`>
what does this mean? can it force 1.8V into 3.3V - 3.3V?
<topi`>
the message from android kernel: "vccio: 1800 <--> 3300 mV at 3300 mV"
<topi`>
does this mean that it is a dynamic range VDD whereas some other regulators are fixed voltage?
<robmur01>
yup, it's an adjustable regulator that the DT says wants to be operated within a particular range (in this case a fixed voltage since min = max), and the kernel found that it wasn't set within that range initially, so fixed it
<topi`>
OK, so it's forced between min and max then
<topi`>
the old 3.x kernel used a different print format, but the same message
<topi`>
I'm trying to see if there are some regulators using different voltages
<topi`>
PHY seems to be dead.
<topi`>
I only find the usbphy's in /sys/class/phy
<topi`>
OK there is Fixed MDIO bus.0 in /sys/devices/platform
<topi`>
i suppose GPIO_A4 is nowadays called RK_A4
<robmur01>
probably the DVS/sleep pins - I don't think they're really used in the upstream driver
<topi`>
in rk808 node, there's nodes like vcc_host, vcc_sys
<topi`>
why does vcc_host need this: gpio = <&gpio0 RK_PB6 GPIO_ACTIVE_HIGH>
<topi`>
vcc_sys does not have a "gpio" line...
<topi`>
I copied these gpio defs from rk3288-evb so they might not match...
<topi`>
but there are no gpio defs in the android kernel. sigh.
<topi`>
my guess is that this GPIO is used for signaling when the regulator is turned on?
<robmur01>
hmm, given the names as well those more sound like plain fixed-regulator nodes; if so, why they would be children of the PMIC node is a mystery, but BSP code is usually the very definition of terrible, so...
<topi`>
this actually came from the rk3288-evb-rk808.dts
<topi`>
so someone has had to approve it ;)
<topi`>
yeah BSP code is beyond horrible, still today...
<topi`>
vcc8-supply = <&vcc_18>;
<topi`>
what's the meaning of this alias?
<topi`>
these vcc*-supply are being listed in Documentation/*/rk808.txt
<topi`>
I feel like an archeologist, trying to see how rk3288.dtsi was written back in 2014
<topi`>
compatible = "arm,cortex-a15";
<topi`>
funny, I thought rk3288 had cortex-a17 (which is a12 actually)
chewitt_ has joined #linux-rockchip
chewitt has quit [Ping timeout: 246 seconds]
stikonas has quit [Ping timeout: 272 seconds]
stikonas has joined #linux-rockchip
camus1 has joined #linux-rockchip
kaspter has quit [Ping timeout: 256 seconds]
camus1 is now known as kaspter
stikonas has quit [Remote host closed the connection]
stikonas has joined #linux-rockchip
ldevulder has quit [Quit: Leaving]
JohnDoe_71Rus has joined #linux-rockchip
chewitt_ is now known as chewitt
stikonas has quit [Remote host closed the connection]
stikonas has joined #linux-rockchip
kaspter has quit [Ping timeout: 256 seconds]
kaspter has joined #linux-rockchip
ldevulder has joined #linux-rockchip
nlhowell has joined #linux-rockchip
stikonas_ has joined #linux-rockchip
stikonas has quit [Ping timeout: 272 seconds]
ldevulder has quit [Quit: Leaving]
nlhowell has quit [Ping timeout: 265 seconds]
vagrantc has joined #linux-rockchip
mraynal has quit [Ping timeout: 240 seconds]
mraynal has joined #linux-rockchip
JohnDoe_71Rus has quit [Ping timeout: 258 seconds]
stikonas has joined #linux-rockchip
stikonas__ has joined #linux-rockchip
stikonas_ has quit [Ping timeout: 272 seconds]
stikonas has quit [Ping timeout: 272 seconds]
robmur01 has quit [Ping timeout: 265 seconds]
vicencb has quit [Quit: Leaving.]
stikonas__ has quit [Remote host closed the connection]
ldevulder has joined #linux-rockchip
robmur01 has joined #linux-rockchip
stikonas has joined #linux-rockchip
vicencb has joined #linux-rockchip
kaspter has quit [Ping timeout: 260 seconds]
camus1 has joined #linux-rockchip
camus1 is now known as kaspter
robmur01 has quit [Ping timeout: 272 seconds]
field^Zzz4 has quit [Ping timeout: 265 seconds]
paulk-leonov has quit [Ping timeout: 260 seconds]
solarsparq has quit [Ping timeout: 265 seconds]
paulk-leonov has joined #linux-rockchip
warpme_ has quit [Read error: Connection reset by peer]
narmstrong has quit [Read error: Connection reset by peer]
steev has quit [Read error: Connection reset by peer]