<mkazantsev>
but in my case all display engine clocks seem to be on, power domains are on, iommu is enabled
<anarsoul>
if BSP works for you, try comparing clock(s) setup
<mkazantsev>
I'll do that
<mkazantsev>
just want to make sure I'm not missing some magic switch
grming has quit [Quit: Konversation terminated!]
apritzel has quit [Ping timeout: 480 seconds]
cnxsoft has joined #linux-sunxi
jason123santaonirc has quit [Read error: Connection reset by peer]
jason123onirc has joined #linux-sunxi
<tlwoerner>
is this a good place to ask about sunxi risc-v support? or is there a better channel for that?
<palmer>
Depending on the question you might get better results on #riscv, but if you're already here it can't hurt to ask
<tlwoerner>
i've been running smaeul's kernel on my nezha and it's been working great. i gave the linux-soc version a try and... not so good
<tlwoerner>
ooh wait. i bet linux-soc doesn't have *all* the bits yet
plaes has quit [Remote host closed the connection]
chewitt has quit [Ping timeout: 480 seconds]
chewitt has joined #linux-sunxi
plaes has joined #linux-sunxi
<smaeul>
tlwoerner: yes, this is a good place to ask. what issues are you seeing with linux-soc, other than missing some of the hardware support?
Net147 has quit [Remote host closed the connection]
Net147 has joined #linux-sunxi
junari__ has joined #linux-sunxi
<tlwoerner>
smaeul: the last thing i see on the console, after U-Boot loads the fitimage, is "Starting kernel ..."
<tlwoerner>
although i'm taking the defconfig from your tree and using it as-is in the linux-soc tree, not sure if that's going to work
junari_ has quit [Ping timeout: 480 seconds]
<smaeul>
tlwoerner: so your problem is that you are using a FIT image. currently U-Boot does not support passing the control FDT to Linux when using a FIT image.
<tlwoerner>
smaeul: ah right. i would need to update the device tree in u-boot from what's in linux-soc for this to work, thanks!
<smaeul>
nope. you have to use the control FDT. you cannot include some FDT in your FIT image, because it will be missing all of the dynamic changes made by OpenSBI and U-Boot
<smaeul>
so you either need to patch U-Boot or not use a FIT image
<tlwoerner>
ah, ok. does it matter that i'm using your u-boot? branch: d1-wip
<tlwoerner>
it sounds like it might be a common/useful feature to have U-Boot be able to dynamically change device trees in a FIT image, is this something that is being worked on in U-Boot?
junari_ has quit [Read error: Connection reset by peer]
junari_ has joined #linux-sunxi
apritzel has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
apritzel has joined #linux-sunxi
<apritzel>
tlwoerner: the whole concept of bundling a devicetree with a kernel (be it in a FIT image or not) is not the right thing to do (TM)
<apritzel>
tlwoerner: as smaeul said: you should update the DT in U-Boot, and use that for everything: old kernels, new kernels, *BSD, you name it
<apritzel>
if you need to manually tweak the DT, for experiments or debugging, use U-Boot's "fdt" command
<gamiee>
What fdt command does?
<gamiee>
And also yes, having DTS in u-boot have many advantages, I'm very thankful to apritzel for letting me know about this, it solved me some things, so I don't need unnecessary DT parched in Linux
<apritzel>
gamiee: you can change anything in the DT on the fly: add nodes, remove nodes, add/remove properties, change properties
<apritzel>
in the early Pine64 days I removed the whole DT, and rebuilt it from scratch, using just the fdt command ;-)
<apritzel>
tlwoerner: if you have bigger changes, there is "fdt apply ...", which applies a DT overlay
<gamiee>
@apritzel: Oh wow, that's really cool! Good to know, thanks!
<gamiee>
(I still need to learn how to write overlays haha)
<apritzel>
it's not that hard, and it got a lot easier a while ago (initially it was quite cumbersome, don't be discouraged if you find early examples)
<karlp>
so, is there any real reason to use fit images? I was having pain with them yesterday due to the sys_bootm_len defaults being too small, and it just realyl sounds like no gain, just to avoid "loading legacy image" text?
junari_ is now known as junari
<junari>
How to configure the dwmac-sun8i driver to work from an external phy сlock source?
mkazantsev has quit [Quit: Leaving]
cnxsoft has quit [Ping timeout: 480 seconds]
<apritzel>
junari: ha, that's work in progress
<apritzel>
junari: you mean it's driven by a PWM clock, right?
<junari>
apritzel: nope, I mean ethernet PHY provide output reference clock
<apritzel>
karlp: I believe FIT images (on the kernel side, not the U-Boot side) are just a convenient way of bundling kernel & initrd, plus potentially other blobs, into one file, the DTB shouldn't really be in there
<apritzel>
junari: sorry, did not get this, can you elaborate? Do you mean any of the *MII clocks?
cnxsoft has joined #linux-sunxi
<junari>
apritzel: In the schema the PHY TXCK pin is configured as 50M output
Net147 has quit [Quit: Quit]
<junari>
I think the dwmac driver is configured as output too
Net147 has joined #linux-sunxi
<apritzel>
junari: still not getting it. What PHY, exactly? RTL8211? Motorcomm? and which pin, exactly?
<apritzel>
if it's about the *MII clocks: that's all handled by the MAC automatically, provided you set the right protocol (MII vs. RGMII, for instance)
<junari>
apritzel: motorcomm YT8512H, TXC pin
<apritzel>
typically the PHYs need a clock input for their own operation logic. That is usually a crystal oscillator, but cheap designs use some SoC clock output to provide that clock
<apritzel>
and this is handled by the MAC hardware, you just need to set it to RGMII
<apritzel>
junari: oh wait, that's RMII on the 8512, so that's the other way around, but still handled by the MAC hardware
<apritzel>
or is it MII?
<junari>
The PHY can configured as "TXC 50Mhz reference clock is output by default" and "TXC 50Mhz reference clock is input". On my board it configured as output. MAC TXCLK should be input in this case
<junari>
Reduced MII
<junari>
I think I need to change the "clocks" and "clock_names" in dts to fixed clock from PHY. But not sure if it will work
<apritzel>
junari: according to the H616 datasheet (that's the SoC, right?), in RMII mode TXC is input on the MAC side, so that should not be a problem?
<apritzel>
and those clocks in the DT are not covering the *MII clocks, those are clocks driving the internal MAC logic
<apritzel>
why is there an external 100MBit PHY in the first place?
<junari>
apritzel: its t507 with emac1 and external motorcomm phy
<apritzel>
oh, was it that the T507 is like the H616, but without the internal PHY?
<junari>
Yes
<junari>
without ac200 or rmii pins not connected to it
chewitt has quit [Quit: Zzz..]
<apritzel>
it's still the same in the T5 series manual: EMAC1 is RMII with TXC being an input
chewitt has joined #linux-sunxi
<apritzel>
the direction of the clock does not seem to be configurable (even though RMII apparently allows both directions)
<junari>
I just remember this feature in NXP soc
DuClare_ has joined #linux-sunxi
<junari>
apritzel: RMII working in H616?
<apritzel>
nobody has tried an external 100MBit PHY, I'd say, because the EMAC1 RMII pins are not exposed on the H616
<apritzel>
and people either use the internal PHY, or an external GBit PHY on EMAC0, using RGMII
<apritzel>
you *can* drive a 100 MBit PHY on EMAC0, with RMII, but no one built this
<junari>
I meant pseudo internal PHY in H616
<apritzel>
junari: also wondering if you have seen that EMAC1 is not yet supported in mainline, you need a small adjustment in sun8i-dwmac.c, to accommodate for the differing syscon offset
chewitt has quit [Quit: Zzz..]
<apritzel>
junari: the integrated PHY is not yet supported in mainline, mainly because AC200/AC300 support is WIP
<junari>
apritzel: I saw this patch, I did it
DuClare has quit [Ping timeout: 480 seconds]
<apritzel>
but I think jernej had this running, with some hacks, and I might have even tried this before as well, but don't remember exactly
<apritzel>
I had one patch to cater for the syscon offset, though this might not be the right solution, let me find that...
<junari>
In that case it should work
<junari>
apritzel: I think I saw this patch
<junari>
I get "dwmac-sun8i 5030000.ethernet: EMAC reset timeout"
<apritzel>
this approach is somewhat obsolete, I believe, given how we support EMAC0 now
<apritzel>
junari: IIRC you would need to use that in the DT: syscon = <&syscon 4>;
<junari>
apritzel: or syscon = <&syscon 1>; ?
<apritzel>
or rather <&syscon 1>, since the driver multiplies by 4 already
<apritzel>
yes ;-)
<junari>
apritzel: So that's not the problem..
<apritzel>
have you checked the PHY connection, in particular the RESET_N and the XTAL pins?
<apritzel>
and if the PHY power supply is enabled?
<apritzel>
XTAL could be a crystal oscillator, or there could be an external clock expected on only one of the pins
<apritzel>
the EPHY_25M clock pin on the T507 is probably very tempting for board vendors to save on the crystal
<junari>
Power, reset, crystal checked
<junari>
the PHY works in the vendor system
<apritzel>
yes, but you might need to enable things, for instance the reset line, or the power
<apritzel>
so is there a separate crystal connected to the PHY? That would remove one problem
junari_ has joined #linux-sunxi
junari is now known as Guest4288
junari_ is now known as junari
<junari>
Yes, it have separate 25M crystal
Guest4288 has quit [Ping timeout: 480 seconds]
junari has quit [Remote host closed the connection]
junari has joined #linux-sunxi
JohnDoe_71Rus has quit []
chewitt has joined #linux-sunxi
yousdo has joined #linux-sunxi
cnxsoft has quit []
JohnDoe_71Rus has joined #linux-sunxi
yousdo has quit []
junari_ has joined #linux-sunxi
junari has quit [Ping timeout: 480 seconds]
junari_ is now known as junari
<junari>
apritzel: it was the wrong PHY address. I don’t understand why, because according to the scheme and datasheet there should be a different value
<jernej>
you can always test with 0 when you're not sure
<apritzel>
ah, nice! the T507 not having the integrated PHY is a good heads up, as we need to make sure we support this (by not hardwiring EMAC1 to the integrated PHY)
<junari>
jernej: how it work?
<jernej>
all PHYs should respond to address 0
<jernej>
independent of their actuall address
<junari>
Interesting. I don't know
chewitt has quit [Quit: Zzz..]
chewitt has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
JohnDoe_71Rus has quit []
grming has joined #linux-sunxi
apritzel has joined #linux-sunxi
junari_ has joined #linux-sunxi
junari has quit [Ping timeout: 480 seconds]
vagrantc has joined #linux-sunxi
bauen1 has quit [Quit: leaving]
grming has quit [Quit: Konversation terminated!]
vagrantc has quit [Quit: leaving]
<smaeul>
apritzel: the problem is that if you don't put a DTB in your FIT, U-Boot uses ATAGS. it doesn't try $fdtcontroladdr.