<shadows>
it is WiFi+BT chipset that can connect with USB or PCIe or SDIO
<emdevt>
so it's wifi module?
<shadows>
yes
<emdevt>
Do you have board where it's equipped or is this custom hardware?
<shadows>
it is official hardware
<emdevt>
Do milk-v provide DTS for that board?
<shadows>
for kernel 5.15, driver is different they use the Android broadcom driver
<emdevt>
ah, that's pain. I just ported one rockchip 5.15 DTS to 6.12 and it took some time!
<la_mettrie>
usbphy is needed in star64 and requires cadence's USB driver? (it's not required in visionfive2, USB can work there with a generic driver)
<emdevt>
What is your target kernel and how you are developing?
<shadows>
la_mettrie: make sure you have U-Boot v2025.07 on Star64
<la_mettrie>
shadows: what difference does it make?
<shadows>
before v2025.07 there is no USB support from U-Boot on Star64
<shadows>
you may then set U-Boot environment fdtfile=invalid and devicetree from U-Boot will allow USB to work with kernel 6.12+
<la_mettrie>
why USB support is needed from U-Boot? aren't kernel drivers self-sufficient?
<shadows>
la_mettrie: nope.
<shadows>
we wish it were better though
<la_mettrie>
are also some other jh7110 drivers dependent on U-Boot?
<shadows>
if you have vendor U-Boot on Pine64 Star64, there are some network problems
<shadows>
the solve recently is that U-Boot board target for JH7110 board variants are now using upstream Linux devicetree-rebasing
<shadows>
so... if you load Linux devicetree file or not, it is not any problem, the flattened devicetree from U-Boot is legitimate to run with for Linux kernel
<shadows>
la_mettrie: USB support for Star64 landed in Linux 6.14, and the USB 3.0 port in Linux 6.15
<shadows>
emdevt: mainline is the target. I have most of the basic features determined (namely eMMC or SD Card, network, USB) but this AP6256 is difficult I don't understand how to make it operate
<la_mettrie>
shadows: what's the connection between "USB 3.0 port" and Star64's USB?
<shadows>
la_mettrie: one of the ports is USB 3.0, three are USB 2.0
<shadows>
for USB 3.0 to be connected it requires to disable one of the two PCIe connections to JH7110
<shadows>
the remaining PCIe connection goes to the physical PCIe slot connector
<la_mettrie>
but don't USB 2.0 ports use that PCIe which is disabled?
<shadows>
I wrote about this at length on LKML discussion and tl;dr the people who designed this are not anymore employees of StarFive so nobody really understands what is going on
<shadows>
it just simply is, and not any documentation that explains the design decision.
<shadows>
la_mettrie: USB2.0 muxes with PCIe (?) from all appearances.
<la_mettrie>
shadows: ...and if PCIe (one used by USBs) is disabled, then USB 2.0 ports don't work?
<shadows>
la_mettrie: I forget, but no, everything works if you have U-Boot v2025.07 and Linux kernel 6.12+ when U-Boot env fdtfile=invalid
<shadows>
if you use Linux 6.15+ then fdtfile env can be deleted and will be selected by eeprom heuristic
<la_mettrie>
in this case it's probably uses (and requires) usbphy and usb's cadence driver
<shadows>
la_mettrie: I'm using Debian 13 Trixie so it will be the Kconfig for that
<la_mettrie>
i wonder what's the purpose of pcie-phy in jh7110. it seems it's not necessary for PCIE
<shadows>
I sure do not know. I'm just dumb enough to try to submit patches to LKML
<dramforever[m]1>
"any pin can connect to any peripheral" isn't even enough, on 7110 any pin can be supplied by any output, and any input can come from any pin, separately
<dramforever[m]1>
the dts doesn't really reflect this flexibility
<ganboing>
Yea, the dts/driver is kind of one way. It's from the view of pins
<dramforever[m]1>
exactly
prabhakalad has joined #riscv
Andre_Z has joined #riscv
prabhakalad has quit [Ping timeout: 252 seconds]
prabhakalad has joined #riscv
itrsea has quit [Remote host closed the connection]
itrsea has joined #riscv
emdevt has quit [Remote host closed the connection]
mps has quit [Quit: leaving]
mps has joined #riscv
ldevulder has quit [Ping timeout: 276 seconds]
ldevulder has joined #riscv
clemens3 has joined #riscv
jacklsw has joined #riscv
jacklsw has quit [Read error: Connection reset by peer]
jacklsw has joined #riscv
Andre_Z has quit [Quit: Leaving.]
mark4o has joined #riscv
markh has quit [Ping timeout: 248 seconds]
mark4o is now known as markh
eden has quit [Ping timeout: 260 seconds]
thanosengine has joined #riscv
tgamblin has joined #riscv
emdevt has joined #riscv
thanosengine has quit [Remote host closed the connection]
jacklsw has quit [Read error: Connection reset by peer]
thanosengine has quit [Remote host closed the connection]
thanosengine has joined #riscv
emdevt has quit [Quit: Leaving]
paulk has quit [Ping timeout: 260 seconds]
paulk has joined #riscv
thanosengine has quit [Remote host closed the connection]
thanosengine has joined #riscv
thanosengine has quit [Remote host closed the connection]
thanosengine has joined #riscv
emdevt has joined #riscv
Andre_Z has quit [Quit: Leaving.]
<remexre>
Has anyone here gotten JTAG working with either the Pine64 Oz64 or Milk-V Duo S? I'm new to this, but it looks like both wired the TDO pin to an LED?
thanosengine has quit [Remote host closed the connection]
emdevt has quit [Ping timeout: 276 seconds]
<drewfustini>
Palmer: patchwork call?
JanC has quit [Killed (zirconium.libera.chat (Nickname regained by services))]
JanC has joined #riscv
ldevulder has quit [Ping timeout: 240 seconds]
ldevulder has joined #riscv
thanosengine has joined #riscv
thanosengine has quit [Ping timeout: 252 seconds]
thanosengine has joined #riscv
coldfeet has joined #riscv
ttydes has joined #riscv
thanosengine has quit [Remote host closed the connection]
thanosengine has joined #riscv
thanosengine has quit [Ping timeout: 252 seconds]
thanosengine has joined #riscv
thanosengine has quit [Remote host closed the connection]
thanosengine has joined #riscv
BootLayer has joined #riscv
thanosengine has quit [Remote host closed the connection]
thanosengine has joined #riscv
thanosengine has quit [Remote host closed the connection]
thanosengine has joined #riscv
coldfeet has quit [Quit: Lost terminal]
ldevulder has quit [Ping timeout: 252 seconds]
thanosengine has quit [Remote host closed the connection]
thanosengine has joined #riscv
thanosengine has quit [Ping timeout: 240 seconds]
thanosengine has joined #riscv
zjason has joined #riscv
LainIwakura has joined #riscv
thanosengine has quit [Remote host closed the connection]
itrsea has quit [Remote host closed the connection]
itrsea has joined #riscv
thanosengine has joined #riscv
cousteau has joined #riscv
thanosengine has quit [Remote host closed the connection]
<shadows>
notes are mmc0 is typically configured as eMMC on VisionFive2 and variants, as it is on the Mars CM (with eMMC), but instead is SD Card on Mars CM Lite (without eMMC) and needs pin 22 to be high; and mmc1 which is typically SD Card is wired to nothing or it is wired to SDIO AP6256 module depending on the product sku what option is there
thanosengine has quit [Remote host closed the connection]
thanosengine has joined #riscv
<dramforever[m]1>
shadows: `wifi_wake_host` needs to be in a `&sysgpio {`, and `wifi_pwrseq` probably needs pinctrl for 33
<shadows>
I'll try it thanks
<dramforever[m]1>
i'm not so sure about the latter
<dramforever[m]1>
if 33 already works without no need to touch it
<dramforever[m]1>
that was the problem right? just wifi_wake_host?
<shadows>
sort of, if I configure the pin then it's a resource that's already claimed and cannot be used by the other mechanisms ?
<dramforever[m]1>
do you mean 33 or 34?
<shadows>
34
<dramforever[m]1>
so 34 is interrupts right
<dramforever[m]1>
<34 IRQ_TYPE_LEVEL_HIGH>
<shadows>
34 is a gpio pin on the schematic, I'm not sure if that counts as an interrupt
<dramforever[m]1>
i mean interrupts = <34 IRQ_TYPE_LEVEL_HIGH>
<dramforever[m]1>
so it depends on whether the driver IRQF_SHARED
<dramforever[m]1>
but also this shouldn't really be a problem, that's just what the pin does
<dramforever[m]1>
i don't understand your question...
<shadows>
there pinctrl is used to configure the pin? and I try the same here but then the error is about using an already in-use resource or something...
<dramforever[m]1>
by "configure the pin" do you mean pinctrl-names and pinctrl-0?
<dramforever[m]1>
ah
thanosengine has quit [Remote host closed the connection]
thanosengine has joined #riscv
<dramforever[m]1>
hmmm... do you have the full kernel log
<dramforever[m]1>
"or something" is a bit hard to diagnose
<shadows>
sure :) I'll uncomment the &wifi_wake_host to invoke the error ?
<shadows>
gpioinfo shows 34 as an output so... hmm
<dramforever[m]1>
aaah you see it looks different from the other nodes
<dramforever[m]1>
under &sysgpio
<dramforever[m]1>
you need an extra nesting
<dramforever[m]1>
so instead of wifi-wake-host { ... }
<shadows>
oh! the grouping or whatever
<dramforever[m]1>
yeah you need an extra group inside
<shadows>
I'll try that
<dramforever[m]1>
yeah it's kinda finicky and honestly i think maybe the pinctrl code saw no child nodes inside and decided "nah it's fine"
prabhakalad has joined #riscv
thanosengine has joined #riscv
<shadows>
so I nest it https://tpaste.us/W5bB to look like that rockchip dts more closely with the nesting, but that wasn't any different error message
<shadows>
I'll try to invert it so it has a child node within the aliased thing, one moment
<dramforever[m]1>
the label wifi_wake_host needs to be on the outer... yeah...
thanosengine has quit [Remote host closed the connection]
<shadows>
I took the firmware files from that, so ... I wonder if that firmware would work with the driver in upstream or not
thanosengine has quit [Remote host closed the connection]
<shadows>
I did try taking commonly available firmware files for AP6256 on raspberry pi that have mainline Linux functionality and using with the vendor kernel, which none of that was successful
thanosengine has joined #riscv
thanosengine has quit [Remote host closed the connection]
<dramforever[m]1>
7110 gpio needs to implement irq_set_wake
<dramforever[m]1>
this might just be an unimplemented thing
<dramforever[m]1>
ah, it could work
thanosengine has quit [Remote host closed the connection]
thanosengine has joined #riscv
<shadows>
I'll try it, will be some time to compile ;)
<dramforever[m]1>
feel free to not respond but are you doing this for work? or just hobby?
<shadows>
hobby
<dramforever[m]1>
nice
<dramforever[m]1>
if this patch works are you going to send this this to lkml?
<dramforever[m]1>
(possibly with the same change to 7100)
<shadows>
yeah however you think it should get upstream, I'll do that
thanosengine has quit [Remote host closed the connection]
<shadows>
strange enough the SDIO attached chipset on 7100 is reported to be functional as-is
thanosengine has joined #riscv
<dramforever[m]1>
on mainline?
<shadows>
affirmative
<shadows>
dramforever[m]1: ganboing has this (JH7100 board) and reports it working, but then important is that the chipset is a different variant that has firmware licensed for distribution in linux-firmware
<dramforever[m]1>
so, the 7110 one doesn't seem to have the wake_host problem
thanosengine has quit [Remote host closed the connection]
thanosengine has joined #riscv
<dramforever[m]1>
so, how do kernel patches like these usually go for debian?
<dramforever[m]1>
i'm currently thinking maybe i can send the patch
<vagrantc>
in general, it is best to get a kernel patch into the upstream branch(es) and then it is generally ok to propose backports in Debian
<vagrantc>
but kernel team is very wary of merging stuff that has not landed upstream, for the most part
<dramforever[m]1>
so, if it's not too inconvenient i think i'll handle sending the pinctrl patches
<dramforever[m]1>
which hopefully will land in 6.16.1
thanosengine has quit [Remote host closed the connection]
<shadows>
dramforever[m]1: feel free to take it, I'll test anything that applies to the hardware I've got in front of me. If I can get a fully troubleshoot workflow done to determine if AP6256 on Milk-V Mars CM / Mars CM Lite is possible or not possible that's the only hold-up I have on my side to submitting those dts to LKML
<dramforever[m]1>
ah sorry i meant to say the initial 6.16
<dramforever[m]1>
but it might be too late
thanosengine has joined #riscv
<shadows>
Conor took my two jh7110 patches saying it might be too late, but those have a PR since Linus did not release on the weekend
<dramforever[m]1>
i'll work on it, but i think we should try to get this brcm thing working on your side first to confirm that this indeed fixes something
<shadows>
agree yes
<dramforever[m]1>
i don't feel like submitting something that fixes a theoretical nice to have
thanosengine has quit [Remote host closed the connection]
thanosengine has joined #riscv
haritz has joined #riscv
haritz has quit [Changing host]
haritz has joined #riscv
thanosengine has quit [Remote host closed the connection]
LainIwakura has joined #riscv
Andre_Z has joined #riscv
LainIwakura has quit [Quit: Client closed]
<conchuod>
yah anything from now is too late for me
<conchuod>
Sent the couple patches I had today, but if something is wrong and needs a fix, I'll get it in as soon as is reasonable.
<shadows>
conchuod: hey just confirming your reply that model goes first before compatible in dts?
<conchuod>
Usually, ye. I don't consider the inverse wrong but I'd take patches converting to model first.
<shadows>
great thank you
itrsea has quit [Remote host closed the connection]
itrsea has joined #riscv
itrsea has quit [Client Quit]
coldfeet has joined #riscv
<shadows>
dramforever[m]1: I got a null dereference on that wake patch with linux kernel 6.12, so... just to be sure I'm taking a bit more time to compile from 6.16-rc7 sources without the changes to rule out any cross-compile toolchain weirdness and then will try with the change again.
BootLayer has quit [Quit: Leaving]
<dramforever[m]1>
ah, hmm
<dramforever[m]1>
that's ... not good
<dramforever[m]1>
shadows: can you just give me the log of the null dereference?
cousteau has quit [Ping timeout: 272 seconds]
thanosengine has joined #riscv
coldfeet has quit [Quit: Lost terminal]
thanosengine has quit [Remote host closed the connection]
thanosengine has joined #riscv
thanosengine has quit [Remote host closed the connection]
<shadows>
dramforever[m]1: https://tpaste.us/waLO null deref output to serial console, lmk if you need more detail this is just what shows up on the console from tty
<dramforever[m]1>
shadows: ah, that's a problem, i misunderstood how the irq_chip thing is structured
<dramforever[m]1>
doing it on 6.16-rc is not going to help
<ganboing>
JH7100/vf1 works fine with upstream kernel and dts. However kernel has to be rebuilt to enable the JH7100/NONPORTABLE configs to workaround non-coherent DMA
___nick___ has quit [Ping timeout: 245 seconds]
<ganboing>
Other than that, there's no change required
<shadows>
we've got that going, the thing powers up and now we're stuck at interrupt related things
<shadows>
I wonder how much of this is dependent on the firmware that gets loaded
<shadows>
I would be okay if it is determined this conclusively is not going to work, or have done all that can be done from dts so I can send this off to the list with that caveat
<dramforever[m]1>
shadows: the interrupt thing? not at all i just completely misunderstood the docs
<dramforever[m]1>
i assumed that the pinctrl drivers mentions "parent" so it probably has a parent domain or something. nope
<shadows>
ah
<dramforever[m]1>
so unfortunately i don't have anything for you or any time soon
<dramforever[m]1>
other than maybe not using the wake pin?
<shadows>
much appreciated anyhow
<shadows>
how would I avoid using it though?
<dramforever[m]1>
ah
<dramforever[m]1>
yeah that doesn't seem possible either...
<dramforever[m]1>
wait
<dramforever[m]1>
it should just work if you just get rid of interrupts = ... and interrupt-names = ...
<dramforever[m]1>
and wifi_wake_host can also just go away for now
<shadows>
didn't I have that before? hmm... will try it now
<dramforever[m]1>
*leave it as off without cleaning, i meant
<dramforever[m]1>
the second alternative i was thinking is after cleaning put it back to initial
<dramforever[m]1>
and on next syscall if it's still at initial don't clean it again
<dramforever[m]1>
i'll put these on the mailing lists
<drewfustini>
thanks, the feedback is helpful. I believe vector off was discussed initially two years ago
<dramforever[m]1>
i don't like vector off anymore
Andre_Z has quit [Quit: Leaving.]
<drewfustini>
> the second alternative i was thinking is after cleaning put it back to initial
<drewfustini>
would that involve checking if it was dirty?
<dramforever[m]1>
again this is missing on details of how these states are already used in linux
<dramforever[m]1>
but i was thinking, to clobber if state is Clean or Dirty, and after clobbering set to Initial
<dramforever[m]1>
so if (VS == Clean || VS == Dirty) { clobber; VS = Initial; }
<dramforever[m]1>
this might contradict how Initial is already used (actual initial might be all zeros?), but i don't think this is unfixable, we just have to make the actual initial and clobbered initial the same
<dramforever[m]1>
(I think Clean means same as saved in memory in linux)
<drewfustini>
there was originally discussion of setting the value to 1's instead of 0's in the linux clobbering assembly. That may be able to help with initia;l
<drewfustini>
> Is it worth clobbering with all 1s, rather than zero, for consistency with other vector behavior (i.e., tail/mask agnostic) and for the reasons givenin the vector spec for not doing so with zero?