frieder has quit [Remote host closed the connection]
frieder has joined #u-boot
milkylainen has quit [Ping timeout: 258 seconds]
sbach has quit [Read error: Connection reset by peer]
sbach has joined #u-boot
milkylainen has joined #u-boot
redbrain has joined #u-boot
milkylainen has quit [Ping timeout: 268 seconds]
tchebb_ is now known as tchebb
alpernebbi has joined #u-boot
wooosaiiii has joined #u-boot
milkylainen has joined #u-boot
<wooosaiiii>
Hi guys, my board has USB otg port, how can I switch between modes e.g. host <> peripheral without changing dr_mode in device-tree and reflashing bootloader?
<milkylainen>
a bit of a yoyo today.
<milkylainen>
wooosaiiii: Why wouldn't you change the dr_mode?
<wooosaiiii>
milkylainen: as I said... then I have to recompile device-tree to change mode
<milkylainen>
Change it in ram?
<milkylainen>
You're talking about changes while running?
<wooosaiiii>
milkylainen: yes
<milkylainen>
So change the tree in ram, fixup whatever needs to be changed and reset subsystem?
<milkylainen>
That would be my initial guess atleast.
<wooosaiiii>
milkylainen: is there a standard way of doing this?
<mwalle>
wooosaiiii: in u-boot? as far as i know, this isn't possible
<milkylainen>
wooosaiiii: I guess either modify the tree with tools or use device tree overlays?
<mwalle>
besides fiddling around in the SPL and modifying the device tree
<wooosaiiii>
mwalle: yes in u-boot... not in the Linux..
<mwalle>
IMHO there is also a problem: if you set it into host mode, usually VBUS is enabled, if its an OTG port, there might be another host connected and then both VBUS voltages will drive against each other
<mwalle>
of course it also depends on the board design, but there is still a chance to make a "short circuit"
<wooosaiiii>
mwalle: this is true... but I have to work somehow around the fact imx8mn only has 1 usb controller
<wooosaiiii>
:)
<mwalle>
wooosaiiii: well if you find a solution, I'll be interested too ;) what would be your trigger to switch modes btw?
<mwalle>
usb id pin?
<milkylainen>
mwalle: Surely U-boot must contain all the functions needed to modify the tree in situ? A somewhat functional libfdt?
<wooosaiiii>
something similar I want in u-boot :)
<mwalle>
milkylainen: otg ususally switches during runtime, but if you modify the device tree its only done on startup. thus if you switch modes, you'd have to reset the board
<milkylainen>
mwalle: Can't reset and remove code and reinsert it? Not strictly as a module, but disable the functionality?
mmu_man has joined #u-boot
georgem has joined #u-boot
<marex>
mwalle: see cmd/bind.c
<marex>
that is for binding/unbinding drivers at runtime
<mwalle>
marex: but you'd still have to modify the device tree on-the-fly
<marex>
mwalle: DT is hardware description, so ... if you modify the DT, does that mean you on-the-fly solder bits and pieces of hardware on/off ?
<mwalle>
well.. u-boot interprets dr_mode = "otg" as peripheral
<mwalle>
marex: ^
<mwalle>
(at least for dwc3)
mranostaj has quit [Ping timeout: 256 seconds]
<mwalle>
marex: and the host/peripheral handling creeped into the device tree anyway.. have a look at how the dwc "otg" support is done in uboot
<mwalle>
there are two different subnodes in the device tree which have no connection to the hardware at all
<marex>
mwalle: badly, the imx ehci handles that otg stuff correctly iirc
<mwalle>
marex: what driver is that? or what source file
<marex>
dwc2.c I suppose ?
<mwalle>
marex: which dts(i) for example?
<marex>
mwalle: does git grep help ?
<marex>
mwalle: iirc altera socfpga did use dwc2 otg, but it's been a while since I tried it
mranostaj has joined #u-boot
<mwalle>
marex: ahh, that device node looks saner, yes
<mwalle>
see for example arch/arm/dts/zynqmp.dtsi how it is done for dwc3..
<marex>
mwalle: btw dwc2 is specific OTG controller, you don;t convert XHCI (another type of controller / standard) to dwc2
<mwalle>
marex: what? linux has a sane representation of the dwc3 controller which is not compatible with the uboot device tree binding
<mwalle>
although IIRC one (xilinx) creeped into linux too..
<marex>
mwalle: so you want to fix the binding in u-boot
<marex>
mwalle: talk to monstr when he's here
<marex>
mwalle: dwc2 is not dwc3 btw, the dwc2 is old designware otg core, dwc3 is new one and is mostly xhci compatible
<mwalle>
marex: xilinx might be special case here though, because its some kind of "glue driver"
<mwalle>
marex: last time I've tried I was under the impression you have to have subnode, because that is how dwc3-generic.c is coded and whats worse is that you have to set the dr_mode, because according to that property either the peripheral driver or the host driver is loaded for the subnode
<marex>
mwalle: you really better talk to Bin Meng and Michal Simek /wrt dwc3
<marex>
mwalle: they should be able to help you
<mwalle>
marex: when i find some time ;) all i wanted to do was dfu and i ended up in a mess of a wrong driver for my soc (drivers/usb/host/xhci-fsl.c) which is host mode only and then the dr_mode = "otg" is really just peripheral mode
<mwalle>
oh and for the icing on top of the cake.. the different representation in the device tree, although as you've already said, the hardware is the same ;)
jwillikers has joined #u-boot
<marex>
mwalle: well complaining isn't gonna fix anything, patches will
<mwalle>
marex: sure, but I just have a limited amount of time ;)
torez has joined #u-boot
tre has quit [Remote host closed the connection]
<marex>
mwalle: sure, I heard many people say this recently
LeSpocky has joined #u-boot
torez has quit [Ping timeout: 252 seconds]
torez has joined #u-boot
<sjg1>
milkylainen_: I believe that is for reading blocks from the underlying UEFI, e.g. to read a kernel, access a filesystem or something
redbrain has quit [Quit: leaving]
<milkylainen>
sjg1: Yes. But how to use it? Barebox lists the devicehandles just fine. I don't need a special emmc driver since barebox piggybacks of the UEFI BLOCK_IO access.
<milkylainen>
sjg1: The idea is that U-boot should pick up the UEFI block io handles and provide access to them under native u-boot disk access.
<milkylainen>
But in U-boot, that does not seem to work properly.
<milkylainen>
sjg1: Mm. Doesn't tell me much though. I still can't figure out how to use it or why/if it is supposed to find the block io guid by itself.
<sjg1>
milkylainen: You could ask Heinrich on the mailing list for tips if something isn't working.
<sjg1>
milkylainen: Is there a command to list the devices?
<milkylainen>
I was hoping that lsblk would list attached devices.
<milkylainen>
it lists an efi_blk driver atleast.
<milkylainen>
efidebug devices and efidebug drivers list some handles and data.
<milkylainen>
But not much otherwise.
<sjg1>
milkylainen: BTW the EFI support was originally written independently of driver mode, to my lasting displeasure. I hope that can be corrected soon and things can be a little more dynamic. At the moment it has its own static data structures
<milkylainen>
Mmm.
<milkylainen>
Anyway. The ACPI enumerated SDHCI (AMD Embedded Ryzen 1000, AMDI0040) solves itself "automatically" by piggybacking UEFI in this regard.
frieder has quit [Ping timeout: 245 seconds]
frieder has joined #u-boot
<sjg1>
milkylainen: Gosh I didn't know that barebox had EFI support now...I wonder if the two projects will ever come back together?
redbrain has joined #u-boot
fdanis is now known as fdanis_away
<milkylainen_>
sjg1: Not likely methinks. For x86, Barebox solves my problems better and more efficiently than U-Boot right now.
sszy has quit [Ping timeout: 256 seconds]
frieder has quit [Remote host closed the connection]
mranostaj has quit [Ping timeout: 248 seconds]
mranostaj has joined #u-boot
macromorgan has quit [Read error: Connection reset by peer]
macromorgan has joined #u-boot
macromorgan has quit [Read error: Connection reset by peer]
macromorgan has joined #u-boot
macromorgan has quit [Read error: Connection reset by peer]
macromorgan has joined #u-boot
macromorgan has quit [Read error: Connection reset by peer]
alpernebbi has quit [Quit: alpernebbi]
<sjg1>
Well that's good news for you I suppose :-)
<marex>
sjg1: add custom shell on top of u-boot and done ?
<milkylainen_>
sjg1: Well. I'd like U-boot to solve my problems too. ;)
redbrain has quit [Quit: leaving]
<marex>
milkylainen_: well, U-Boot is collaborative project, it depends on contributions, it is not a resource which can be indefinitelly consumed and will never deplete
<milkylainen_>
marex: Sure. Right now I don't even have an answer if the code works or not. Or reasonable description of it.
<milkylainen_>
I sent a mail to the mailing list. Hope someone can answer.
<marex>
milkylainen_: what does xypron Heinrich say ?
<marex>
milkylainen_: see, you are consuming a resource now ;)
<milkylainen_>
marex: I haven't heard anything yet.
<marex>
I havent seen xypron here for a while either, I wonder what happened
torez has quit [Quit: torez]
<milkylainen_>
vaccation? :)
birkoff has quit [Ping timeout: 240 seconds]
<sjg1>
milkylainen_: Did you send an email to the list?
<marex>
sjg1: < milkylainen_> I sent a mail to the mailing list. Hope someone can answer.
<marex>
sjg1: looks like the answer is yes, five lines above
<milkylainen_>
I did?
<milkylainen_>
sjg1: ok.tnx.
<sjg1>
xypron: ^
agust has quit [Ping timeout: 272 seconds]
jwillikers has quit [Remote host closed the connection]