<tuxd3v>
I keeprebooting, if I dount that it works, I will post a working case :)
<tuxd3v>
dount-> know...I need my glasses on :)
pnill has joined #linux-sunxi
ganbold has joined #linux-sunxi
<apritzel>
I had a working case before, but I need one now, with my debug prints in
<tuxd3v>
ho.. so you need to reboot too :/
<apritzel>
yeah, tried some times, now finally got a working case
<tuxd3v>
when its working, the kernel per see, shows the patch, that was uploaded to the bluetooth device its version and the name and such in dmesg
<tuxd3v>
then you just need as root to run:
<tuxd3v>
bluetoothctl show
<tuxd3v>
and it will print to you all the information, etc
jernej has joined #linux-sunxi
<tuxd3v>
the problem is, that majority of times it doesn't work and you receive "No default controller available"
<tuxd3v>
you can try to force powering it up, but it still doesn't show in the bluetooth deamon :(
<pnill>
apritzel: somewhere along the line I broke my normal USB and can't fix it now -_-
<pnill>
lol
<tuxd3v>
hciconfig hci0 up
<apritzel>
tuxd3v: yes, I understand all that, and that's not the problem
<tuxd3v>
it takes some time to load the firmware patch to bluetooth, then you see the log messages in kernel , But bluetoothctl will continue to show you "No default controller available"
<apritzel>
the device doesn't work early, and the reset command times out
<tuxd3v>
indeed
<apritzel>
the rest you see are all fall outs from this very problem
<tuxd3v>
yup
<pnill>
Since I was playing with the OTG gadget stuff I haven't really messed with this, I recall you saying disabling the OCHI devices and such you were able to get gadget working but I can't get normal USB working with a normal configuration now and everything should be how it was before... outside of maybe config changes to kernel but I can't see anything that would cause this musb is in dual mode... boot log: https://pastebin.com/raw/0t6wENuq dts:
<pnill>
I do see this now though: [ 0.165991] sun4i-usb-phy 5100400.phy: failed to get clock usb0_phy
<pnill>
I don't recall seeing that before.
<pnill>
and: [ 1.815896] usb_phy_generic usb_phy_generic.1.auto: supply vcc not found, using dummy regulator
<pnill>
been messing with dts/menuconfig for a good hour or so playing with stuff trying to get it working again lol
<pnill>
guess I should check if there's power going to the port, previously when that wasn't happening that's when you'd recommended adding the usb0_id_det-gpios line
qschulz has quit [Quit: qschulz]
<apritzel>
pnill: but what board is this again? Do you actually have a micro-USB port on controller 0?
<pnill>
I believe so, it's that board for that arcade.
qschulz has joined #linux-sunxi
<pnill>
but the dts I gave is from the tanix h6 (it's an allwinner h6 soc)
<pnill>
just modified for the pinout found on this board/information gathered before
<apritzel>
yeah, I was confused about that Tanix in there
<apritzel>
because those TV boxes don't have micro USB
<pnill>
yeah... I just recalled using the tanix config before when I was messing with it
<pnill>
have .bash_history that shows as much as well lol
<pnill>
been about a week since I touched it
<pnill>
You and I both had been trying to get the OTG stuff working, I think you ultimately determined that the OCHI controller had to be disabled to get it
<apritzel>
pnill: what is this reg_usb1_vbus? Where is this defined
<pnill>
but I ended up using a USB network adapter at some point
<apritzel>
pnill: well, the question is whether you want to have true OTG or not
<apritzel>
true OTG requires the ID pin *and* switchable VBUS on that port
<pnill>
at the moment was just trying to get my network adapter working again lol
<apritzel>
if you want to force it to host, that should be easy
<pnill>
dr_mode in otg, and dual mode on the musb configuration in the kernel worked as far as I recall
<pnill>
but it's not feeding power to the micro usb atm.
<apritzel>
just set dr_mode = "host" (and enable EHCI0/OHCI0, of course)
<apritzel>
pnill: at the moment I wonder how this DT compiled for you
<pnill>
I actually dunno where ®_usb1_vbus is defined
<apritzel>
exactly, it's only in some board .dts files
<apritzel>
they all define it and use it later
<pnill>
yeah now wondering myself how it was compiling lol
<apritzel>
pnill: how did you learn about the ID pin GPIO (PL5)?
<pnill>
the original dts off the board
<pnill>
you're actually the one who pointed it out afaik
<apritzel>
is there any hint about a VBUS switch in there?
<apritzel>
and I learned that those DTs are highly unreliable
<apritzel>
on some TV box it said PL5 is the power key (the box doesn't have one), and also it controlling VBUS (which is always on)
<apritzel>
so there seems to be a lot of wrong copy&paste from some template DT in those ones
<pnill>
it looks like I've some how lost the reg_usb1_vbus line that was in here I wonder if when I lost power to my whole system the VM didn't sync to disk or something.
<pnill>
Apr 27 15:27:36 <apritzel>but at least you found the USB issue now, didn't you? You need to copy the reg_usb1_vbus node from sun50i-a64-orangepi-win.dts (for instance)
<pnill>
as that was something you'd told me to copy before
<apritzel>
yes, you need the *node* and the *reference* to it
<pnill>
yeah
<apritzel>
PC6 is mentioned as the VBUS switch in this DT
<pnill>
you'd mentioned both before
<pnill>
I'm honestly not sure how it got removed, or how it compiled with out it.
<apritzel>
but you did have eMMC on that board, didn't you?
<pnill>
yeah
<apritzel>
because PC6 is SDC2-D0
<apritzel>
which means it's an essential line for eMMC operation
<apritzel>
wasn't it that you found some GPIO that switches power to the USB port?
<pnill>
yeah, I think that's where r_pio 0 5 GPIO_ACTIVE_HIGH came from
<apritzel>
PL5 is apparently the ID pin input
<apritzel>
you should be able to verify this, by plugging in a host and a device cable
<pnill>
nah, I copied and pasted that in the wrong place.
<apritzel>
the GPIO should read a different level then
<pnill>
basically you'd said something about it
<pnill>
but you'd said it right after mentioning reg_usb1_vbus
<pnill>
so I'm assuming it went inside that block as the pin to enable USB
<pnill>
(power wise)
<apritzel>
well, this can't be the one pin to rule them all ;-)
<apritzel>
you'd need one for the ID pin and one to switch power (if that switch actually exists)
<apritzel>
that's what I meant with the DT being unreliable: PC6 can't be USB power and eMMC D0 at the same time
<pnill>
This is what we'd said before
<apritzel>
yeah, but PC6 is apparently wrong
<apritzel>
for peripheral mode to work you need to disabled OHCI0/EHCI0
<apritzel>
I realised that it was actually me breaking this lately
<pnill>
which could be why it was unstable in switching between gadget and host?
<pnill>
yeah, that's what you'd said before too
<pnill>
lol
<pnill>
but I'm not trying to do the peripheral atm
<pnill>
was just trying to get the port working again
<pnill>
and I think it was that vbus stuff missing
<pnill>
because the port has power now
<apritzel>
if that's the case, then just set dr_mode to "host", and enable OHCI0/EHCI0
<apritzel>
that should work
<apritzel>
you can reference the reg_vcc5v for the supply, but don't need to
<pnill>
"I realised that it was actually me breaking this lately"
<pnill>
something you contributed code wise?
<apritzel>
yes
<pnill>
ouch
<pnill>
lol
<pnill>
I don't trust committing code to anything as large as this
<apritzel>
putting phys = <&usbphy 0>; to the EHCI0/OHCI0 nodes
<pnill>
because I know my code sucks
<pnill>
not saying yours does but yeah..
<apritzel>
which now makes the MUSB OTG controller fight with the EHCI/OHCI controller over the port
<pnill>
so what would be the solution then?
<apritzel>
that is arguable a bug in the USB PHY
<pnill>
I don't really know how usb works at the kernel level tbh
<apritzel>
the solution (more a workaround) is to disable the HCI controllers
<apritzel>
you don't need them (and never will) in peripheral mode anyway
<apritzel>
well, the actual solution is to teach the USB PHY to deal with this properly
<apritzel>
it does make the right decision in OTG mode, and has extra code to deal with this
<apritzel>
but if it sees peripheral, it doesn't take that extra case
<apritzel>
care*
<apritzel>
and if the HCI0 controller are enabled, they request PHY0 (*before* the OTG controller does), and the PHY give it to them, enabling host mode
<apritzel>
but it shouldn't do this, when "peripheral" is selected
jstefanop has joined #linux-sunxi
jstefanop has quit [Ping timeout: 252 seconds]
<apritzel>
tuxd3v: so far comparing dmesg between working and failing didn't give any clues, that all looked the same
<tuxd3v>
yeah except for the loaded firmware
<apritzel>
again, red herring
<apritzel>
it fails already before loading the firmware
<apritzel>
I was checking power supplies and the UART as well
<apritzel>
so power sounds promising, but in your case it's the system 3.3V
<apritzel>
so can't be it
<apritzel>
it could be some timing issue, but that's harder to debug
<apritzel>
except for maybe putting some delay in probe() and see if that fixes the problem
<tuxd3v>
some timing, yeah it could be
<pnill>
apritzel: : so yeah, adding the vbus made it work again
<pnill>
guess that was missing just amazed it was compiling with that missing
apritzel has quit [Ping timeout: 240 seconds]
<vagrantc>
anyone heard of issues with ethernet not working on H3 with linux 5.10.x ?
<vagrantc>
apparently in the devicetree it needs:
<vagrantc>
- phy-mode = "rgmii";
<vagrantc>
+ phy-mode = "rgmii-id";
<vagrantc>
similar to a900cac3750b9f0b8f5ed0503d9c6359532f644d ARM: dts: sun7i: a20: bananapro: Fix ethernet phy-mode
victhor has quit [Ping timeout: 240 seconds]
gaston1980 has quit [Ping timeout: 240 seconds]
suniel has joined #linux-sunxi
gaston1980 has joined #linux-sunxi
<wens>
we tried to patch all the device trees, though some errors may have slipped through
<vagrantc>
it would seem sun8i-h3-orangepi-plus needs it too
pnill has quit [Read error: Connection reset by peer]
suniel has quit [Ping timeout: 240 seconds]
pnill has joined #linux-sunxi
buzzmarshall has quit [Remote host closed the connection]
jstefanop has joined #linux-sunxi
jstefanop has quit [Ping timeout: 260 seconds]
vagrantc has quit [Quit: leaving]
apritzel has joined #linux-sunxi
iamfrankenstein has joined #linux-sunxi
chewitt has quit [Quit: Adios!]
cnxsoft has joined #linux-sunxi
cnxsoft1 has quit [Ping timeout: 240 seconds]
jstefanop has joined #linux-sunxi
suniel has joined #linux-sunxi
cmeerw has joined #linux-sunxi
ganbold_ has joined #linux-sunxi
netlynx has joined #linux-sunxi
netlynx has quit [Changing host]
netlynx has joined #linux-sunxi
ganbold has quit [Ping timeout: 268 seconds]
mmarc__ has joined #linux-sunxi
mmarc__ has quit [Ping timeout: 260 seconds]
mmarc__ has joined #linux-sunxi
hexdump01 has joined #linux-sunxi
mmarc___ has joined #linux-sunxi
<hexdump01>
i hope it is ok to ask a not directly sunxi question here (as i think someone here can for sure answer it quickly)?
mmarc____ has joined #linux-sunxi
mmarc__ has quit [Ping timeout: 260 seconds]
suniel has quit [Ping timeout: 240 seconds]
<apritzel>
hexdump01: as the topic says: don't ask to ask. Just ask ...
<hexdump01>
how to interpret /sys/kernel/debug/devices_deferred - does the order have any meaning in there and what would an entry like '7-0008' in there mean? any pointer to some info or doc about devices_deferred would be welcome too - i did not yet find anything which helped me further ...
<apritzel>
it shows the content of the deferred pending list, with the device name first, then a reason (which might be empty) after a tab
<apritzel>
for the meaning of pending list, see the comment at the top of this file
Mangy_Dog has joined #linux-sunxi
<hexdump01>
apritzel: the basic idea is clear to me - its just i'm trying to make sense of the content and try to understand what to make out of '7-0008' there :)
mmarc__ has joined #linux-sunxi
mmarc__ has quit [Remote host closed the connection]
mmarc__ has joined #linux-sunxi
<hexdump01>
apritzel: i guess its some id but have no idea what it might be - there are other entries with names i have an idea what they are
mmarc__ has quit [Remote host closed the connection]
<apritzel>
well, it's what dev_name(dev) returned for a device, I guess?
<apritzel>
and my understanding is that this list should be empty after boot
<apritzel>
if not, it means some devices are still missing resources
<hexdump01>
apritzel: ok - thx a lot
cnxsoft has quit [Remote host closed the connection]
<apritzel>
hexdump01: but tbh I haven't heard to this file before, so thanks for the heads up ;-)
<hexdump01>
apritzel: :)
mmarc__ has joined #linux-sunxi
victhor has joined #linux-sunxi
<smaeul>
why of course that refers to the device at address 8 on bus number 7 ;)
<smaeul>
hexdump01: `find /sys/devices -name 7-0008` would give you a bus path
<smaeul>
and booting with initcall_debug will tell you the name of the function that returned -EPROBE_DEFER, which will lead you to a driver
<hexdump01>
smaeul: cool - this tells me what it actually is - thanks a lot
putti_ has quit [Ping timeout: 265 seconds]
<apritzel>
smaeul, jernej: dumping my H616 USB progress so far:
Putti has joined #linux-sunxi
<apritzel>
- the DT from my h616-v6-WIP branch works - with all USB ports enabled in isolation - WHEN booted via FEL
<apritzel>
- when booting from SD card, only port 2 works
<apritzel>
(when just this is enabled)
<apritzel>
- when booting from SD card and enabling *all* USB ports, they all work (!)
<apritzel>
- with that DT and SD card boot, adding all the other PHYS and the other RST_BUS_EHCIx, RST_USB_PHYx, CLK_USB_PHYx references does NOT help (to enable port1)
<apritzel>
jernej: your PRCM bits from the BROM were already set the same in both SD and FEL boot
<apritzel>
jernej: since from U-Boot on it's the same between SD and FEL, I didn't try to disable/enable or follow a sequence
mmarc__ has quit [Remote host closed the connection]
specing_ has joined #linux-sunxi
specing has quit [Ping timeout: 240 seconds]
specing_ is now known as specing
<apritzel>
smaeul: how long did you test to see those 10 bit failures?
<apritzel>
smaeul: you mention "_extremely_" rare, in 1 out of 8 boards?
<apritzel>
I wonder how long I would need to run a test before trying another board
mmarc__ has joined #linux-sunxi
choozy has joined #linux-sunxi
mmarc__ has quit [Ping timeout: 252 seconds]
JohnDoe_71Rus has joined #linux-sunxi
mmarc__ has joined #linux-sunxi
mmarc__ has quit [Ping timeout: 245 seconds]
jstein has joined #linux-sunxi
xes has quit [Ping timeout: 252 seconds]
buzzmarshall has joined #linux-sunxi
xes has joined #linux-sunxi
mmarc__ has joined #linux-sunxi
lurchi_ has joined #linux-sunxi
lurchi_ has quit [Client Quit]
mmarc__ has quit [Ping timeout: 268 seconds]
jbrown has quit [Ping timeout: 260 seconds]
Kooda has quit [Quit: issued !quit command]
Kooda has joined #linux-sunxi
jbrown has joined #linux-sunxi
gsz has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
lucascastro has joined #linux-sunxi
gaston1980 has quit [Remote host closed the connection]
<megi>
looks like not adding the phys property and patching the hdmi driver to not look for it and just probe the phy regardless woudl also fix it
<megi>
avoiding the whole situation
<megi>
though DT is probably not supposed to be changed
<megi>
not sure if there are any other phys than the internal one ever used
<megi>
probably not
<smaeul>
apritzel: did you see my earlier messages explaining what BROM does? it disables HCI 2 PMU SIDDQ to get USB 0 working, so you need an actual <&usbphy 2> reference from each controller, not just the clocks/resets
<megi>
jernej: do you remember the reason for why hdmi phy is not implemented as a separate platform device?
warpme_ has joined #linux-sunxi
<smaeul>
apritzel: on my PinePhone 1.0 (that 1/8 device), I got errors past the kernel on 5 runs out of 32 consecutive runs of the test tool
<smaeul>
they never seem to happen once "warmed up", only when first running the tool, or when running the single-threaded test (which hops CPUs)
<smaeul>
so if you're using your bare-metal tool, I'd suggest adding some random occasional WFEs or something
choozy has quit [Ping timeout: 245 seconds]
mmarc__ has joined #linux-sunxi
jstefanop has joined #linux-sunxi
mmarc__ has quit [Ping timeout: 265 seconds]
jstefanop has quit [Ping timeout: 252 seconds]
shailangsa has quit [Ping timeout: 240 seconds]
choozy has joined #linux-sunxi
mmarc__ has joined #linux-sunxi
<pnill>
apritzel: So, usb gadgets did work after disabling OCHI/etc... as you'd said just further confirming it.
buzzmarshall has quit [Remote host closed the connection]
mmarc__ has quit [Remote host closed the connection]
<apritzel>
pnill: good, thanks! and fixing this properly is on my list, but there are some higher priority items on there
<pnill>
yeah had some weird issues with stability that I think may've been related to my VM, as when I moved to my mac they were completely gone
<pnill>
but beyond that worked great.
<apritzel>
smaeul: yes, I saw your comments on the BROM, many thanks! I started digging into the BROM, but haven't finished that yet.
<apritzel>
smaeul: I was hoping for something easy to integrate into the existing PHY code, so need to check what clearing other PHY's SIDDQ would take
netlynx has quit [Quit: Ex-Chat]
victhor has quit [Read error: Connection reset by peer]
mmarc__ has joined #linux-sunxi
shailangsa has joined #linux-sunxi
dev1990 has joined #linux-sunxi
<jernej>
megi: you can't avoid phys property - that part is tightly connected with controller
<jernej>
like you must observe some specific power up sequence
mmarc__ has quit [Remote host closed the connection]
<megi>
the driver seems to just call the phy probe directly after reading the phy property anyway
<jernej>
and PHY implements callbacks which are used by controller setup code
<megi>
the wholed DT thing seems a bit superfluous
<jernej>
megi: right, it must be after, not before
<jernej>
wait
<megi>
right, so if it would be a separate device the order would be reversed
<jernej>
but anyway, PHY driver must not setup clocks and resets before controller
<megi>
anyway, hw requires that phy_probe is done after hdmi device probe?
<jernej>
yes
<megi>
ok
<megi>
good to know :)
<jernej>
and it must provide set of callbacks
<megi>
we'll get some feedback soon from fw_devlink/core maintainers so this is important to know
<jernej>
it can be implemented by PHY subsystem, but it's more clunky
<jernej>
because standalone driver must provide some methods, which needs to be exported and special header file needs to be put in include/ folder
<jernej>
and I doubt we would do that in RC phase
<megi>
it's possible to just break the fwnode_link, because it doesn't make sense in this case... one way to do it would be to get ridof the phys property
<megi>
anyway, daydreaming since DT change probably would not be accepted
<jernej>
there is a thing called DT rules :)
<megi>
but it will work in my tree until a proper upstream solution is found
<megi>
;)
<megi>
there are other fw_devlink issues in sunxi code, so I can at least workaround this one to get to see the others :)
<megi>
eh, I have to rename it in all the dtsi files... bah
<megi>
yeah, rename fixed the display
<apritzel>
megi: please don't mess with compatible strings, not even in "your" tree
<megi>
i didn't change compatibles
<megi>
just phys property
<megi>
I can even do it in a backwards compatible way by making the driver check both names
<apritzel>
but not forward compatible, I guess?
<tuxd3v>
apritzel, I didn't give up yet on bluetooth
<apritzel>
tuxd3v: me neither ;-)
<tuxd3v>
I still continue testing, and trying to get paterns , to see were they lead me..
<megi>
that depends on what lays forward :)
<megi>
but probably no
<apritzel>
megi: meaning the most recent DTs work on older kernels
<apritzel>
megi: in general I doubt that a DT change to fix some Linux driver model issue is the right answer
<megi>
we agree on that
<megi>
I just need the kernel to boot to test other things
<megi>
I'm not proposing this as final solution :)
<apritzel>
megi: good, just wanted to make sure
<apritzel>
tuxd3v: I wanted to test some older kernels, which version are you using?
<tuxd3v>
I am on 5.10.36
<apritzel>
that's sad!
<tuxd3v>
do you think messing with uboot will improve our chances to get that working?
<tuxd3v>
next time you try, try later a reset
<megi>
looks like kernel should be able to infer that some devices can't be probed and re-order the probe sequence already, but it probably doesn't do it for "toplevel" platform devices
<tuxd3v>
you see a reset timout in the dmesg
<apritzel>
tuxd3v: U-Boot should have no role in this at all
<smaeul>
jernej: so it sounds like the root issue is that the PHY probe function shouldn't be enabling clocks/resets. those should be moved to a phy ->init or ->power_on callback
<tuxd3v>
apritzel, after boot, do 'bluetoothctl show'
<tuxd3v>
if it doesn't work, reset hci0 device 'hciconfig hci0 reset'
<tuxd3v>
then test bluetooth 'bluetoothctl show'
<tuxd3v>
if it doesn't work, remove and insert hci_uart module:
<tuxd3v>
modprobe -r hci_uart;
<tuxd3v>
modprobe hci_uart;
<tuxd3v>
check bluetooth again :)
<tuxd3v>
nope forget.. :/
hramrach has quit [Ping timeout: 252 seconds]
hexdump01 has left #linux-sunxi ["WeeChat 1.9.1"]
hramrach has joined #linux-sunxi
luke-jr has quit [Read error: Connection reset by peer]
luke-jr has joined #linux-sunxi
jstefanop has joined #linux-sunxi
jstefanop has quit [Ping timeout: 252 seconds]
hlauer has quit [Ping timeout: 252 seconds]
ganbold__ has joined #linux-sunxi
ganbold_ has quit [Ping timeout: 268 seconds]
<apritzel>
tuxd3v: I don't understand: we don't need some weird way to get BT to work, we need to find the root cause why it doesn't work in the first place
warpme_ has quit [Quit: Connection closed for inactivity]
<apritzel>
smaeul: jernej: when I reboot a H616 board from the kernel, I see "Failed to set core voltage! Can't set CPU frequency" in the SPL
<apritzel>
this is because the SPL speaks only I2C to the PMIC, but the kernel left the AXP in RSB mode
<apritzel>
and while the RSB got reset by the watchdog, the AXP didn't
<apritzel>
so shall we put the AXP back into I2C mode in the kernel, for instance in drivers/mfd/axp20x-rsb.c:axp20x_rsb_remove()?
<smaeul>
then how would TF-A communicate with it?
<smaeul>
you'll have to update u-boot to use RSB
<apritzel>
meh, that's in the SPL, and we just use the existing I2C SPL driver
<apritzel>
but yeah, TF-A is really the last one to use the AXP
popolon has quit [Quit: WeeChat 3.1]
<apritzel>
or actually, it doesn't *use* it in the case of reset
<apritzel>
but it could send this one command to set it back into I2C?
<apritzel>
smaeul: didn't we do something similar before, for some other SoC?
<smaeul>
we set it back to I2C during boot
<smaeul>
but you can't communicate with it after you do that, so you lose the ability to do a PMIC reset instead of a watchdog reset
<apritzel>
so that the kernel can go through the original init sequence, right?
<smaeul>
yeah
<apritzel>
PMIC reset? I thought we always reset via the watchdog?
<smaeul>
TF-A does, yes, so there's no regression -- but it would prevent you from doing so in the future
<smaeul>
also you can't do it in the kernel because that would break crust
<apritzel>
smaeul: do you rely on the AXP being in RSB mode in crust? (I know, doesn't apply to the H616, just in general)
<apritzel>
;-)
<smaeul>
I rely on it being in the same mode during both sleep and shutdown/reboot
<smaeul>
whether that's I2C or RSB is configurable at build time
<apritzel>
I see
<smaeul>
and there's definitely not space for both drivers :)
<smaeul>
what's the problem with using RSB in SPL? there's already a driver
<apritzel>
that's for some old SoC only, IIRC? Need to check whether that works with the H616?
<smaeul>
you'll have to do that anyway when we move to using the DT in SPL, since that's what's in the DT ;-)
<smaeul>
it looks like it would work. it's not like the RSB controller has changed since it was added
<apritzel>
DT in SPL? begone evil spirit!
<smaeul>
(on the other hand, things that have changed recently: the GPIO register layout, which will be a massive pain for u-boot)
<apritzel>
smaeul: OK, thanks for your input, will have a think about it
<apritzel>
it doesn't seem to be critical, interestingly, the CPU clock is set up correctly anyway, regardless of this message
<smaeul>
maybe the frequency it is setting is what's already set up by the BROM?
<smaeul>
the voltage will be whatever was used by the OPP at reboot (which is probably high) so it works out
<apritzel>
yeah, the voltage is definitely correct in this case, also for the DRAM (which would be more critical to set up, really)
<apritzel>
the value of CPUX_PLL is 0xba001100, which is 432 MHz
<apritzel>
is that what the BROM uses?
<smaeul>
I don't know offhand
<apritzel>
anyway, the CPU really runs at 432 MHz after a reset, that's a bit annoying
<apritzel>
mmh, the BROM seems to use 408 MHz
<apritzel>
anyway, back to the actual showstopper: USB ...
<apritzel>
smaeul: ... and of course clearing SIDDQ in PMU2 does the trick
<apritzel>
interestingly even across a PHY2/EHCI2 reset