<geertu>
Esmil: There's a difference between the default in Kconfig, and enabling a driver in defconfig
XYZ89 has joined #riscv
<Esmil>
right, but whatever is not specified in the defconfig will be the default in Kconfig
<geertu>
So you can have "default m" in Kconfig, and override to =y in defconfig (if Ethernet =y)
<Esmil>
geertu: so does that mean you think aon and dwmac-starfive should be m in Kconfig, and Hal should instead try to get =y into the defconfig?
craigo_ has joined #riscv
<geertu>
Esmil: I didn't follow things that closely. What is an "always-on clock controller"?
<geertu>
The bindings lack a top-level description section
<geertu>
will reply to the series...
<Esmil>
my understanding is that it's different clock domains. so for the JH7110 the tree is basically oscillator -> 3 plls -> sys crg clocks -> { aon clocks, stg clocks, vout clocks, isp clocks }
craigo has quit [Ping timeout: 276 seconds]
<Esmil>
and there is a driver for each memory block controlling the sys, aon, stg, vout and isp clocks
<Esmil>
right now only sys default to y since that's all that's needod to boot into an initramfs where further modules can be loaded
<Esmil>
what Hal is saying is that the aon clock driver should also default y since one of the two ethernet ports depend on aon clocks
<geertu>
But the Ethernet driver does not default to y (only in defconfig), right?
<geertu>
And whether the Ethernet is used depends on the board, not on the SoC.
<Esmil>
well Samin's latest version did default y and i asked him to make it default m
<Esmil>
..but now i'm wondering if i was wrong
jacklsw has joined #riscv
ldevulder has quit [Ping timeout: 255 seconds]
jay321 has joined #riscv
jay321 has quit [Ping timeout: 268 seconds]
MaxGanzII has joined #riscv
<Tenkawa>
Esmil: I saw a fair number of new changes in your jh7110 branch the other day... Is it worth re-testing yet or still serial only still?
<Esmil>
Tenkawa: serial, mmc (sdcard) and ethernet (temperature sensor and watchdog maybe)
<Tenkawa>
Mostly just waiting on the usb to be functional.. once it is I can start testing a lot more
<Esmil>
StarFive also sent usb 2.0 recently, but I didn't manage to get it working :(
<Tenkawa>
I need to get another repeater... my house coverage for my lan is too spread out
<mps>
Esmil: this is for visionfive v2 and not v1?
<Tenkawa>
It takes 50+ ft cables right now if I want to use lan
<Esmil>
mps: yes
<Tenkawa>
mps: yes
<mps>
eh, would be nice to have one kernel for both
MaxGanzII has quit [Ping timeout: 255 seconds]
<Esmil>
mps: oh, i actually have that locally. just didn't push it anywhere yet
<Tenkawa>
It works fine with vendor but I want to help out and push forward with the mainline effort
<mps>
if I got V2 board I will have to maintain separate kernels for v1 and v2
<mps>
Esmil: I guess it takes time to make one kernel for both but if you push it please inform me. I will be grateful
MaxGanzII has joined #riscv
ldevulder has joined #riscv
<mps>
Tenkawa: I agree that best option to push patches to mainline
<mps>
s/to/is to/
<Tenkawa>
mps: after my last 10+ years of fighting it in the ARM world....
pedja has joined #riscv
<Tenkawa>
The vendor specific tied kernels/drivers are a bit much
jay321 has joined #riscv
aerkiaga has joined #riscv
<bjdooks>
the v1 and v2 really should be just a device tree change
<Esmil>
bjdooks: ? the VisionFive V1 uses the JH7100 "test chip" and the VisionFive 2 uses the JH7110 that I think they're actually trying to sell
elastic_dog has quit [Ping timeout: 252 seconds]
elastic_dog has joined #riscv
<geertu>
Esmil: I guess bjdooks responded to "maintain separate kernels for v1 and v2"
<geertu>
The old days of bootloaders not updating /chosen/bootargs in appended DTBs are long gone (hmm), so no need for separate kernels!
aerkiaga has quit [Remote host closed the connection]
jay321 has quit [Remote host closed the connection]
jay321 has joined #riscv
<jrtc27>
v1 needs cache coherency hacks that the v2 doesn't
<pierce>
jrtc27: can't that be a quirk that
<pierce>
* quirk that's enabled from what's in the device tree?
<jrtc27>
yes, but the point is it's totally plausible for v2 development to happen in a branch that doesn't have the v1 hacky crap
<Tenkawa>
It would be cleaner to keep them unattached from each other unless you want to end up in a ifdef cascade later
<Tenkawa>
That's not a dependency tree I want to think about in SCCS
<geertu>
Last time /me used the SCCS format was with BK...
<Tenkawa>
geertu: I mean SCCS in general (git/cvs/svn) any of them
<Tenkawa>
its a generic term
<geertu>
Ah, generic VCS
elastic_dog has quit [Ping timeout: 255 seconds]
<Tenkawa>
Yeah
<Tenkawa>
I started with RCS and Sablime
<Tenkawa>
back in the dark ages
elastic_dog has joined #riscv
<geertu>
The Dark Ages before git, when we suffered from RCS/CVS/ClearCase/SVN
<Tenkawa>
ClearCase.... shudder
<bjdooks>
ClearCase, the ideal storage for all open source software... non
<Tenkawa>
haahaa
Andre_Z has joined #riscv
XYZ89 has quit [Ping timeout: 260 seconds]
XYZ89 has joined #riscv
Andre_Z has quit [Quit: Leaving.]
terminalpusher has joined #riscv
Andre_Z has joined #riscv
terminalpusher has quit [Remote host closed the connection]
MaxGanzII has quit [Remote host closed the connection]
MaxGanzII has joined #riscv
MaxGanzII has quit [Remote host closed the connection]
MaxGanzII has joined #riscv
Armand has joined #riscv
jacklsw has quit [Quit: Back to the real life]
motherfsck has joined #riscv
craigo_ has quit [Quit: Leaving]
prabhakarlad has quit [Quit: Client closed]
<conchuod>
Esmil: defconfig needs a bit of an overhaul, it was only for the allwinner stuff that Palmer decreed that it was okay to add soc drivers as modules a la arm64
<palmer>
I don't think I really had a strong opinion here, just sort of a "defconfig should be useful for kernel devs, which means it should boot on the common dev boards"
<conchuod>
I dunno if my opinion really matters, but I'm okay with y for clocks, resets, serial & ethernet there /shrug
<palmer>
at least clock/reset/serial should be Y, boxes are pretty useless without them ;)
<conchuod>
That'll get us booting, but not really all that much more, which I think is fine.
<conchuod>
Esmil: In the subsystems, I dunno. Probably the same logic applies, so that random folk get given the defaults that make sense? Module anything that is not needed to get off the ground?
cwebber has quit [Remote host closed the connection]
<Esmil>
conchuod: yeah, module anything that's not needed to see the serial console as you boot into an initrd that lets you load more drivers is what i've been going for. so that also means module clock drivers for graphics and video codecs
raym has quit [Quit: kernel update, rebooting...]
<Esmil>
..but then my question is if that's too minimal and ethernet should also be considered essential
<Esmil>
Because then the aon clock driver and the dwmac-starfive should also be default y
<jrtc27>
depends if you've also got storage IMO
<jrtc27>
if no storage then networking isn't all that useful
<jrtc27>
(I assume NFS etc are not in defconfig)
<jrtc27>
if you have storage then there's an argument to be made for being able to boot to a headless ssh server
<conchuod>
It is in defconfig
<Esmil>
the sys clocks are enough for mmc (sdcard), but the board also has an m.2 slot for an nvme drive. for that you'd also need the stg clocks and the pcie driver default y
<jrtc27>
because people like to netboot?
<conchuod>
Esmil: It's a rabbit hole, stop!
<Esmil>
conchuod: exactly!
<conchuod>
I'll go reply to the thread, obv. I'm not the maintainer so it's not definitive but I'll make a suggestion :)
<mtinman[m]>
conchuod: General Ackbar says, "It's a trap!"
<conchuod>
pierce: effectively the jh7100 non-coherent stuff can be a "quick based on devicetree", I think it just currently isn't and there are #defined bits in the jh7100 kernel
<conchuod>
There's work to be done to get it to that point..
<Esmil>
conchuod: the jh7100 patches right now is not suitable for upstream, but the non-coherent stuff does actually key off the devicetree and isn't just #defined
<pierce>
That's cool. I think I share the same sentiment as others that having fragmented kernels should be avoided where possible
<conchuod>
Esmil: Oh cool. I've got non-coherency on the brain right now, so I've completely forgotten what was in the stuff Cristian sent
<Esmil>
in fact i regularly boot the some binary kernel on both the vf1, vf2, unmatched and icicle boards just to check that it works
jay321 has quit [Remote host closed the connection]
<mps>
Esmil: nice, it boots on v1, uname -a show 'Linux vf 6.2.0-1-starfive #2-Alpine SMP PREEMPT Thu, 09 Mar 2023 21:15:50 +0000 riscv64 GNU/Linux'
<Esmil>
yeah, the vf1 should works as well as ever, but there something is up with Xingyu's stg clock/reset driver in that tree, so the trng and usb on the vf2 can't deassert the resets :/
<mps>
ethernet doesn't work on v1 though. but this is not urgent
<Esmil>
you probably need to enable CONFIG_DWMAC_STARFIVE
<mps>
ethtool tool shows that the link detected
<mps>
interface is detected and it is up but ping doesn't work
<mps>
and CONFIG_DWMAC_STARFIVE is enabled as module
<mps>
but not urgent for me
<Esmil>
interesting. it works on my vf1
<Esmil>
does your kernel log say something about not detecting the phy?
<Tenkawa>
mps: make sure to test both cables... (the v1.2 units all have the 100mb/1gb glitch right?)
<Tenkawa>
er cables/ports
<Esmil>
Tenkawa: the vf1 only has 1 port
<Tenkawa>
not sure which ver you have
<Tenkawa>
oh didnt see he said vf1
<Tenkawa>
my bad
<mps>
Tenkawa: same cable work fine with previous Esmils v1 kernel