cnxsoft has quit [Remote host closed the connection]
codekipper has quit [Ping timeout: 480 seconds]
jason123santaonirc has joined #linux-sunxi
jason123onirc has quit [Remote host closed the connection]
cnxsoft1 has quit []
apritzel has quit [Ping timeout: 480 seconds]
JohnDoe_71Rus has quit []
sh1 has quit [Ping timeout: 480 seconds]
hlauer has joined #linux-sunxi
sh1 has joined #linux-sunxi
hlauer has quit [Ping timeout: 480 seconds]
<blathijs>
Anyone here familiar with the MUSB kernel code for sunxi? I'm debugging an issue with the Orange Pi PC (H3) running Armbian where it fails to enable VBUS on its OTG port. I've seen that everything else works (If I force the regulator to be on, I can plug in USB devices and everything seems to work). I've added some debug prints to the kernel and found that phy-sun4i-usb.c
<blathijs>
correctly reads the ID pin and sets the EXTCON_USB_HOST flag, which *should* cause musb/sunxi.c to enable power (through phy_power_on()), but this does not happen because the musb device is never enabled/started.
<blathijs>
Now it looks like musb_start should be called to fix this, but it also looks like that is only done when the musb controller is really being used. In this case, there is a companion EHCI/OHCI controller that used for USB host mode, so I believe it would be incorrect to actually start the musb device.
<blathijs>
But blaming shows that check has always been there, but I can't imagine that host-mode is and has always been broken on these "dual route" boards
<blathijs>
Ah, maybe I realize the problem - In the upstream kernel source, I could not find any code that actually disables musb host controller for these dual route boards, just code that reroutes the PHY to EHCI/HOST, but I think that there is an Armbian-specific patch that disables musb, and presumably that patch was not tested for usb host mode, I guess.
apritzel has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
<apritzel>
blathijs: I wonder how many boards actually use host mode on port 0 on the H3? It's probably just those TV boxes? As most dev boards have a microUSB port connected, and enough "proper" host ports?
<MoeIcenowy>
apritzel: blathijs: I think the problem is raised by wiring PHY0 to HCIs
<MoeIcenowy>
this is technically correct, unfortunately this is not allowed now
<MoeIcenowy>
blathijs: could you try to revert "ARM: dts: sunxi: H3/H5: Add phys property to USB HCI0" ?
<apritzel>
MoeIcenowy: heh ;-)
<apritzel>
but that might indeed have triggered it
<MoeIcenowy>
well in fact I did this previously on A64, and found it breaks OTG
<MoeIcenowy>
apritzel: BTW for boards that will want OTG, I now have one -- I bought a second handed 3d printer, and its previous owner used an Orange Pi One to run Klipper
<MoeIcenowy>
(a USB port is used to communicate with the MCU of the 3D printer, so I have 0 host-only and 1 OTG ports left
<apritzel>
MoeIcenowy: yeah, I understand, it just does not seem very common for H3 boards, in contrast to A64 ones, for instance
<blathijs>
apritzel: OTG micro-usb also does not enable VBUS when connecting a micro-to-usb-a adapter.
<apritzel>
blathijs: yeah, I think I saw this before, at some time, but then got lost in the rabbit hole of this whole code
<MoeIcenowy>
blathijs: when I develop the dual-mode code
<MoeIcenowy>
I expect the MUSB to be always-on to manage OTG
<MoeIcenowy>
and HCIs to be enabled if host mode is desired, and MUSB gets switched out when otg host mode
<apritzel>
MoeIcenowy: but the MUSB driver is not really needed for OTG detection, is it? That's just GPIOs, and the PHY DT node?
<MoeIcenowy>
apritzel: maybe we should make a virtual PHY that is corresponding to the HCIs, and get HCIs connected to the virtual PHY
<MoeIcenowy>
apritzel: theortically it is, but HCIs are not OTG-aware
<apritzel>
blathijs: did you try a pure mainline kernel?
<MoeIcenowy>
and an OTG-aware controller is needed
<blathijs>
apritzel: No, I wouldn't know where to start :-)
<MoeIcenowy>
blathijs: just build one and put the kernel file and DT to where the Armbian kernel used to be
<blathijs>
AFAIU the PHY is connected to MUSB and not EHCI/OHCI, because EHCI/OHCI would just keep the PHY (and also VBUS) enabled all the time instead of doing OTG.
<MoeIcenowy>
blathijs: yes
<MoeIcenowy>
blathijs: in fact I think you can try to revert the problematic patch?
<MoeIcenowy>
with Armbian build system, just delete it
<blathijs>
MoeIcenowy: Yeah, I'll do that. I came here because I was stuck debugging, but after explaining my question I realized what the problematic patch was (and then I had lunch break ;-p), so let's see if that helps indeed.
<apritzel>
I agree that the current OTG code is somewhat broken in mainline, though I don't think it should be more dependent on the MUSB driver
<MoeIcenowy>
apritzel: yes it should get less dependent
<apritzel>
OTG detection just needs the PHY and GPIOs, IIUC
<apritzel>
(plus help of the PMIC, maybe)
<MoeIcenowy>
maybe we should change the way phy-sun4i-usb handles OTG?
<MoeIcenowy>
e.g. let it enable vbus only when host, etc
<apritzel>
that sounds like the cleanest approach to me, yes
<MoeIcenowy>
and we need to prevent *HCI from claiming the PHY as host-only
<blathijs>
apritzel: I think that MUSB is now only involved as a forwarding agent (PHY detects id pin, sets EXTCON_USB_HOST, MUSB subscribes to that and calls phy_power_on which actually enables VBUS)
<MoeIcenowy>
(this is why previous HCI0 is not attached to PHY
<MoeIcenowy>
blathijs: yes it is
<MoeIcenowy>
maybe I should get the things better when implementing it
<apritzel>
I am fine as long as we don't take the "phys" properties away from the HCI DT nodes again
<MoeIcenowy>
apritzel: I am thinking about creating a virtual PHY for host ports
<MoeIcenowy>
e.g. for H3, <&usbphy 0x04> or <&usbphy 0x1000>
<MoeIcenowy>
and leave 0x0 for musb
<apritzel>
I don't think we should change the DT (in an incompatible way)
<MoeIcenowy>
apritzel: but are we ready for sharing a PHY cell?
<MoeIcenowy>
I don't think it appropriate patching HCI driver for some specific SoC
<MoeIcenowy>
apritzel: I think at least from no PHY to <&usbphy RAND_NUM> is not incompatible
<blathijs>
You're slowly losing me in the details of the solutions you are discussing, but I'm happy that you are and I would agree that ideally MUSB would not be involved at all here. A virtual host-only phy seems like a reasonable approach, from my very limited understanding on how all this fits together :-)
<blathijs>
At first glance it seems that reverting
junari has quit []
<gamiee>
blathijs: np :)
<apritzel>
just be a bit careful as this document's content is basically unchanged since its merge in 2014
<gamiee>
:( musb
<gamiee>
oops :D
<blathijs>
At first glance it seems that reverting usb-musb-sunxi-Avoid-enabling-host-side-code-on-SoCs-where-it-s.patch does not actually help - PHY is still not powered on. It does seem that patch was correctly reverted, since the "Disabling musb host" line and I see some (I think) new "MUSB HDRC host driver" line, but the PHY and VBUS are still not enabled. I'm not entirely sure if
<blathijs>
musb_start is now called (I messed up my debug output), checking that now.
<blathijs>
Yup, musb_has_gadget() returns 0, which prevents musb_start from being called.
<blathijs>
MoeIcenowy: apritzel: Could you help me understand musb_has_gadget()? The name and comment imply that this checks whether any gadget drivers are registere or something, but the implementation actually seems to check if musb is configured for host-only mode (note that it does not seem to return 1 in OTG-host-mode, since musb->port_mode seems to be set on initialization only based,
<blathijs>
function name, so that now makes now sense. Also, it seems that that commit assumes that port_mode is actually updated on role changes, which is not (currently) the case..
<blathijs>
Seems that was already the case when that patch was applied, so maybe it was based on misunderstanding, then...
<blathijs>
Let's see if mainline boots and what that does...
cnxsoft has quit []
<apritzel>
blathijs: I do believe that proper OTG operation (actual runtime role switch) might have been broken for a while (read: years) already
<gamiee>
apritzel: but "hard config to OTG in DT" should work finely right? Just no DMA ?
<apritzel>
yes
<gamiee>
great! Although, we still don't have any example of USB Device DMA, right? (that's what I remember)
<apritzel>
gamiee: let's try to walk before we run, and get proper OTG functional first ;-)
<gamiee>
true :D
DmSi has joined #linux-sunxi
DmSi has quit []
<blathijs>
What is "hard config to OTG"? I understand hard config to peripheral or host, but the entire point of OTG is to switch automatically instead of hardcoding, right?
grming has joined #linux-sunxi
<apritzel>
I think "hard wired to peripheral" is what gamiee meant
<gamiee>
correct, that's what I meant
<blathijs>
That would make more sense :-)
<apritzel>
blathijs: "OTG" and "peripheral mode" seem to be commonly use for the same thing
<apritzel>
OTG is more widely understood, I think
<blathijs>
I just booted a mainline kernel (by using CREATE_PATCHES=yes and then just reset the patches armbian had already applied), and it shows the same behavior: musb host is initialized, a hub power set is done, but musb_has_gadget returns 0, so PHY is not enabled.
<blathijs>
I suspect that hardwiring the mode to host might help for my particular usecase (I really only need host mode, but I do not want to force vbus on in case someone *does* try to connect with a A-to-B cable), but actual roleswitching would be better.
<blathijs>
I wonder if the roleswitching *does* work on devices where the MUSB host mode is actually used (i.e. platforms that do not also have an EHCI/OHCI controller), or that it is just broken for all sunxi musb hardware...
<blathijs>
I suspect the latter, due to this musb_has_gadget issue. So maybe musb_has_gadget should be fixed for those devices, and for the ones with EHCI/OHCI, musb host controller should be sidestepped (maybe even omitted at compiletime?) entirely?
<apritzel>
blathijs: so when I tested my patch to connect the *HCI0 nodes to the PHY as well in the DT, I think I tried hardwired modes on an H5 (OrangePi PC2), and it worked there
<apritzel>
and this patch actually allows to use port0 in host mode without having the MUSB driver loaded/compiled in
<apritzel>
(which is one reason for having this patch, another one is that U-Boot relies on "phys" properties)
<blathijs>
apritzel: Ah, you mentioned this patch before. I do not have that patch in my tree currently. When I was debugging earlier, I had a small eureka moment when I noticed that hci0 was missing the phys property, thinking I had cracked the problem. However, I also tried adding the property, but according to the original patch notes, this causes VBUS to *always* be enabled, breaking
<apritzel>
blathijs: I sent this patch in November only, and it is mainline since v6.2-rc1, so it's pretty new
<apritzel>
if nothing else, not having PHY properties in the HCI node is a hack around this particular Linux implementation detail (HCI always turns VBUS on)
<blathijs>
apritzel: Yeah, I'm still at 6.1. But do I see it correctly that applying that patch essentially forces USB host mode and unconditionally enables VBUS, ignoring the ID pin? I don't think I've tested this though, I just took those patch notes for true
<blathijs>
apritzel: Agreed that this could be seen as a hack, but it *is* a hack that prevents the magic smoke from escaping right now in case someone connects these boards as devices anyway?
<apritzel>
I don't think it forces host mode, that is set by the PHY, not the HCI
<apritzel>
it might keep VBUS on, though
<apritzel>
and I am pretty sure I tested at least forced peripheral mode on the OPi PC2, and I think even OTG
<blathijs>
Yeah, the latter. So that's maybe even worse - when connecting to another host you get no host mode (because the signal is routed to musb periph), but you *do* get VBUS
<blathijs>
Maybe forced peripheral mode does not initialize the HCD? Though I'm not sure if there is any check in that codepath, other than disabling the hci in dt maybe.
<apritzel>
so I think the role detection via the ID pin works, and it switches the PHY MUX correctly. So when we want host mode, the MUSB is not connected to the pins anymore, and the HCIs take over
<blathijs>
Yes, that is also my observation.
<apritzel>
on the other hand if the ID pin says peripheral, the HCIs are out, and the MUSB is connected
<apritzel>
that is somewhat independent of VBUS control, though
<blathijs>
Also my understanding, yes.
<apritzel>
and there is also VBUS detection, which I am not sure works at all
<blathijs>
But I'm concerned for the case when someone assumes that OTG or peripheral is supported, connects that, and gets competing 5V supplies, which sounds like a recipe for smoke.
<blathijs>
I don't think vbus detection has any pin configured or even connected on this board (orange pi pc), nor am I sure how that is supposed to work at all.
<apritzel>
blathijs: theoretically I agree, but competing VBUS is happening all of the time on Allwinner boards, and so far I haven't seen any problem
<apritzel>
some boards hardwire VBUS (to A ports), but I regularly connect A-A cables, for the BootROM FEL mode, and this is not really a problem
<apritzel>
most PC USB ports have decent electrical protection, I think, and at the worst there is some error current due to different voltages, no?
<apritzel>
I am not saying we should officially support or endorse this, but just saying that this is typically not a reason for smoke
<blathijs>
I guess protections (and cable resistance) will generally help and not lead to immediate smoke, though I see the orange pi pc board has regulator outputs wired directly to its USB ports, so connecting two of these boards together might still be somewhat problematic. But I see your point, maybe I'm oversensitive to competing regulators and things are more relaxed in USB
<blathijs>
environements ;-)
<apritzel>
smaeul: right, I think I was fine with this patch, might have fallen through the cracks, or I wanted to find a proper test for this still ...
<apritzel>
blathijs: I would hope that USB is pretty robust against those issues, given its exposure to those ... "users" ;-)
<blathijs>
Hm, I made an attempt to try your patch to get you some feedback, but it seems I failed to apply get Armbian to apply it properly, I found out after booting it (and am slowly running out of time now...)
<apritzel>
blathijs: while hope dies last, I think the patch doesn't fix any OTG operation. Definitely it was never meant to ;-)
<blathijs>
apritzel: I wasn't expecting it to :-)
<apritzel>
but reading the last sentence of my commit message again, I saw an improvement in host mode switching
<blathijs>
Also, I thought that (as an alternative to your patch) setting dr_mode on the musb devicetree would give me host-only operation with proper (safe) VBUS on/off behavior (just no working peripheral mode), but it turns out that if you force dr_mode=host, the PHY driver also ignores the id pin and just stays in HOST mode, so VBUS stays on as well.
<blathijs>
In any case, I think I'm just going to force the regulator to be enabled with a dt overlay (that's the easiest to integrate in my build process and seems to give the same results as other approaches - working host mode and fixed VBUS). Then my client can at least start building and testing their solution (which needs only host mode), and maybe I can offer a bit of help with
<blathijs>
making OTG work properly again (mostly testing, I think, since I do not feel familiar enough with the code to propose solutions).
<apritzel>
blathijs: so your device has a micro-B socket, with the ID pin wired up, but you want to primarily use it in host mode, with an OTG adaptor cable?
vagrantc has joined #linux-sunxi
<apritzel>
because I think this is what works, and which might have actually been improved with this patch, according to my testing back then, at least
vagrantc has quit [Quit: leaving]
<blathijs>
apritzel: That is correct. And I also think it works with your patch, but the net effect of forcing the regulator on without your patch is the same (host works, VBUS is always on), but is slightly easier to integrate in my build system than a kernel patch.
<blathijs>
Is there any bugtracker where this problem could be reported and I could share my observations and conclusions so far? Or would a post on the sunxi mailing list be most appropriate?
<smaeul>
kernel bug tracker? what is this, the 21st century? ;)
<blathijs>
In any case, thanks for the link to that thread, it does show that most of the things I have been discovering are already known, and it seems Evgeny Boger has some proposed proper solution already, so not sure if my posting to the list is going to add something now (at least not until I looked at their proposed solution).
ftg has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
JohnDoe_71Rus has quit []
apritzel has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
reasonx has joined #linux-sunxi
reasonx has quit [Remote host closed the connection]
reasonx has joined #linux-sunxi
apritzel has joined #linux-sunxi
reasonx has quit []
reasonx has joined #linux-sunxi
<apritzel>
blathijs: posting to the mailing list is always good, and be it to signal that there is more than one person affected by this or interested in fixing this
<apritzel>
poor Evgeny was fighting a somewhat lonely fight there, where most people just said: meh
<blathijs>
apritzel: Good point. I'll have a read over Evgeny's patches this week (that should fit in between other work stuff) and then post something armed with than info :-)
<apritzel>
the sunxi ml has a rather limited range, though, CC:ing other MLs brings in people more heavily invested and versed in USB-OTG, I guess
<apritzel>
using scripts/get_maintainer.pl -f <filename> on some key files should give you some more ideas
vagrantc has joined #linux-sunxi
reasonx has quit [Remote host closed the connection]
vagrantc has quit [Quit: leaving]
<apritzel>
smaeul: so what is the NAND support status in U-Boot? Does this work with MLC? Can one boot from this? And this only for the older SoCs (pre-H3)?
<apritzel>
I have an H3 and a H6 TV box with raw (MLC) NAND (did not plan for this, but "paid" for buying the cheapest available), would this be usable?
<apritzel>
I was under the impression that MLC NAND support is mostly a lost cause, and no one uses SLC these days anymore ...
<smaeul>
apritzel: worse than linux. SLC only. I have a series where I cherry-picked 32 patches from Linux (starting with 46c135c208a3a80bd7f12dee0032bbc6d507a0d9, for context) before I gave up
<smaeul>
I don't think MLC is a lost cause; it just requires effort, which nobody is interested in
<smaeul>
IIRC the reason I gave up (at 511d05e0dadd91d398ed14f043fbcc93d728b98c) is because the patches started requiring newer features from the MTD core that hadn't been ported to U-Boot
<smaeul>
also U-Boot doesn't even match the allwinner,sun8i-a23-nand-controller compatible. only the SPL code supports A23/A33
<smaeul>
I don't have short-term plans to improve the driver; this series was about SPL_DM and the craziness that is `enum fdt_compat_id`
reasonx has joined #linux-sunxi
reasonx has quit []
Rtry2 has joined #linux-sunxi
<apritzel>
OK, thanks. And yeah, with "lost cause" I meant that "more effort that the average person is willing to invest to bring this up in a mainlineable fashion"
Rtry2 has quit []
reasonx has joined #linux-sunxi
<reasonx>
test again
<reasonx>
Oh nice, im here =)
<reasonx>
Hello guys. Im trying to build and launch mainline u-boot on mine cubieboard2 A20 using SD card
<reasonx>
And i have stuck on next: Seems eGon starts SPL and SPL try to load u-boot true sdc1 (Trying to boot from MMC1)
<reasonx>
on this step everything hangs
<reasonx>
im tried to enable MMC log and see, what it reads 512b blocks on 0x50 address (by block as i understand, so it is 0xA000 binary).
<reasonx>
and drop connection to MMC1 after this
<reasonx>
And there is next stange things:
<reasonx>
cubieboard doesnt have SDC1(MMC1???) it have only SDC0 (not placed on mine board version_
<reasonx>
so it seems, what SPL is loaded from SDC2(MMC2) and after it, tries to boot from SDC1
<reasonx>
but i cant find option to switch this in u-boot menuconfig
<reasonx>
can you help me?
<reasonx>
Im tried to change "mmc extra slot number" but nothing is changed
<reasonx>
also, im doesnt place anything on sd card, except uboot-with-spl.bin
<reasonx>
nor make any partitions
<smaeul>
there are multiple numbering schemes involved here, which is confusing, but the "MMC1" in "Trying to boot from MMC1" refers to the SD card, what Allwinner would call "SDC0"
<reasonx>
It is not mistake. Im confused too. I dont know how SDCx is aliased by MMCx