≡
[12:46:11] <marex-cloud> xcko: U-Boot and USB keyboard problems?
[12:46:43] <marex-cloud> Is that mainline U-Boot or some hacked up vendor fork?
[12:47:05] <jo0nas> marex-cloud: Mainline u-boot fails to detect Teres-I keyboard
[12:47:16] <marex-cloud> Fails how?
[12:47:30] <marex-cloud> Didn't know mainline U-Boot supported the board
[12:48:01] <jo0nas> It does since ~May when I pushed some patches
[12:48:11] <marex-cloud> Ah good
[12:49:12] <jo0nas> marex-cloud: do you have access to the backlog of this room? Then please read backlog, it should explain how it fails
[12:50:30] <marex-cloud> I don't see the board in mainline , what's the DT file name?
[12:51:17] <marex-cloud> jo0nas: is that the internal keyboard that has issues?
[12:51:21] <jo0nas> configs/teres_i_defconfig
[12:52:03] <marex-cloud> jo0nas: I just recall someone had issues with some weird keyboard on rpi recently, there were even some patches posted, but the keyboard they used was some total broken trash
[12:52:09] <jo0nas> the theory is that the keyboard first presents itself as something else than a keyboard for a few seconds, and the u-boot driver fails to handle that (even if later reset)
[12:53:23] <marex-cloud> Something else?
[12:53:24] <jo0nas> yes it is the Teres-I keyboard - as backlog indicates, plugging in another USB-based keyboard gets recognized by u-boot driver
[12:53:55] <jo0nas> did you read backlog?
[12:54:00] <marex-cloud> No
[12:55:23] <marex-cloud> Just saw that U-Boot might have a bug in USB hid code, so I figured I might ask what's going on
[12:56:09] <jo0nas> you're welcome!
[12:56:12] <marex-cloud> There's an environment variable to keep vbus on for longer before probing the USB bus
[12:56:48] <marex-cloud> So if your keyboard needs to be powered up for a bit before it can be correctly recognized, that might help?
[12:56:51] <jo0nas> I tried that without success (but I might be doing something wrong - please do retry!)
[12:57:16] <marex-cloud> I don't have the board, I just maintain the USB in U-Boot
[12:57:32] <jo0nas> also, I suspect if delay would help then reset would work too
[12:57:35] <jo0nas> ah
[12:58:10] <jo0nas> so you offer expert insight to the u-boot driver - awesome!
[12:58:24] <marex-cloud> Ah, here it is
[12:59:00] <marex-cloud> setenv usb_pgood_delay 2000 ; usb reset
[12:59:04] <marex-cloud> Try that ^
[12:59:28] <jo0nas> ACTION pulls out his Teres-I...
[12:59:53] <marex-cloud> That will turn on the vbus , wait 2 seconds , the probe the bus
[13:01:37] <marex-cloud> Also look at https://patchwork.ozlabs.org/project/uboot/list/?series=123624
[13:01:57] <marex-cloud> But that applied to dwc2, so I dunno if that affects you too
[13:02:35] <jo0nas> thanks - still setting up the laptop (or rather, borrowing the laptop from my partner - I managed to break the screen on my own)
[13:03:30] <marex-cloud> No stress
[13:03:59] <jo0nas> :-)
[13:04:24] <jo0nas> ACTION excited there's hope to get this fixed!
[13:05:27] <jo0nas> that keyboard issue is possibly the last annoying detail blocking my recomming the Teres-I for my mom and others less technically interested
[13:05:51] <jo0nas> recommending*
[13:08:06] <marex-cloud> GPU?
[13:08:46] <jo0nas> not crucial for my needs
[13:09:00] <jo0nas> ...but certainly nice to have
[13:09:37] <jo0nas> ACTION does not equate non-tech users with GNOME, but am content with Xfce
[13:11:15] <marex-cloud> As the screens become bigger, doing composition with CPU is becoming a problem. Plus browsers use gpu for composition extensively
[13:12:00] <marex-cloud> But with Mali Txx, panfrost might soon be an option
[13:12:06] <jo0nas> indeed
[13:25:43] <jo0nas> whoah - that worked!
[13:27:00] <jo0nas> I guess I can then compare with include/configs/nitrogen6x.h for a patch to mainline U-boot
[13:27:07] <jo0nas> thanks a lot, marex-cloud!
[13:28:16] <jo0nas> uhhh, no
[13:28:26] <marex-cloud> Heh
[13:29:31] <jo0nas> I was thrown into ramfs shell - that's where keyboard worked
[13:29:43] <jo0nas> initramfs, I mean
[13:29:55] <jo0nas> still no working keyboard in u-boot
[13:30:22] <marex-cloud> So what does usb reset print?
[13:30:37] <marex-cloud> With that pgood delay set that is
[13:31:02] <jo0nas> let me find my serial cable to inspect this properly - it was rolling by too quickly
[13:33:23] <marex-cloud> jo0nas: no stress, slow down, that always helps
[13:35:16] <jo0nas> keyboard works!
[13:35:59] <marex-cloud> jo0nas: even after full power cycle?
[13:36:17] <jo0nas> interrupting boot from serial port, setting the variable, resetting USB - then keyboard works
[13:36:26] <marex-cloud> jo0nas: is that with or without the pgood delay?
[13:36:27] <marex-cloud> Oh
[13:36:50] <marex-cloud> And , after a power cycle, without the pgood delay, it does not?
[13:37:29] <jo0nas> power-cycle, repeating the voodoo, keyboard works
[13:38:05] <jo0nas> oh!
[13:38:22] <jo0nas> power-cycle, replacing voodoo with simple "usb reset", keyboard works
[13:38:53] <jo0nas> this is a newer u-boot than the one I fought with in the spring - perhaps you fixed it since then?
[13:39:27] <jo0nas> this is U-Boot 2019.01+dfsg-7 (from Debian sid)
[13:40:32] <jo0nas> ACTION goes to test with older U-boot in Debian buster (and grabs some breakfast while at it)
[13:45:22] <marex-cloud> jo0nas: uh, try U-Boot master please ;-)
[13:45:57] <marex-cloud> We're at 2019.10-rc2 already, although I guess vagrantc isn't gonna update the U-Boot in debian stable for obvious reasons
[13:46:41] <jo0nas> works in U-Boot 2019.01+dfsg-7 as well
[13:48:12] <jo0nas> vagrantc is quite hesitant to deviate from upstream, but can be convinced to carry reasonably-small backports - as he did for the Teres-I patches that I got into mainline for 2019.4 which is also included in 2019.01+dfsg-7
[13:49:44] <jo0nas> uhhh, wait: I just realize now that I am talking about exact same version for buster and sid - gotta be my mistake in how I make my images...
[13:50:35] <jo0nas> marex-cloud: Yes, I do understand that from a development POV I should work on HEAD of mainline U-boot
[13:51:19] <jo0nas> ...but quite interesting to me is that this works even with the older U-boot in stable Debian (needs only a "usb reset")
[13:51:56] <marex-cloud> jo0nas: would be at least good to test mainline here and there, to see if it still works
[13:52:31] <marex-cloud> jo0nas: so you can now somehow install regular debian on the laptop and it just works? That's nice
[13:53:14] <jo0nas> exactly!
[13:54:28] <jo0nas> yes, part of my pushing those patches for Teres-I to mainline U-boot was also that I added my name as maintainer - so I should certainly test from time to time that it still works - regardless of Debian release cycle
[13:54:56] <marex-cloud> jo0nas: so what's the story with the USB? It just works now?
[13:55:11] <marex-cloud> Why didn't it work before?
[13:55:20] <jo0nas> requires "usb reset" - doesn't work otherwise
[13:56:31] <jo0nas> possibly this worked for some time and what I haven't been able to make work is having that "usb reset" be part of the builtin code
[13:57:45] <jo0nas> ...and if that is true, then possibly that's because I really need to wait and then do reset (my manually intervening on serial port takes more than 2 seconds)
[13:58:08] <marex-cloud> Hold on
[13:58:10] <jo0nas> makes sense?
[13:58:41] <marex-cloud> You always have to do usb reset (or usb start), otherwise the bus isn't probed and the keyboard won't be found and registered
[13:58:49] <jo0nas> oh
[13:59:13] <marex-cloud> There's no automatic detection of USB peripherals, like in Linux
[13:59:26] <marex-cloud> It's all on demand
[14:00:03] <marex-cloud> So if you need USB ( or if the bus configuration changed somehow, e.g. you plugged something in ) , do usb reset
[14:00:24] <jo0nas> so "CONFIG_USB_EHCI_HCD=y" only builds the driver, doesn't ensure it is loaded?
[14:01:11] <marex-cloud> The driver is bound , so U-Boot driver model instantiates the controller driver on boot
[14:01:34] <marex-cloud> But only if the USB is needed is the controller initialized and the bus scanned
[14:01:55] <jo0nas> not sure what that means
[14:01:58] <marex-cloud> It's to ensure the boot is as fast as possible, without initializing useless stuff
[14:02:14] <marex-cloud> If you need something, you need to say so
[14:02:25] <jo0nas> in config?
[14:02:43] <jo0nas> uh, that was ambiguous
[14:02:50] <marex-cloud> On the command line (orn through dependencies between drivers)
[14:02:55] <jo0nas> by declaring env vars?
[14:03:18] <marex-cloud> All right, let's try again
[14:03:36] <marex-cloud> So to reach U-Boot command line, you only need serial console, right?
[14:04:00] <jo0nas> correct
[14:04:01] <marex-cloud> Ok, to get serial console, the uart driver must be compiled in
[14:04:37] <jo0nas> USB gets loaded automatically, yes
[14:04:44] <jo0nas> and then I interrrupt the countdown
[14:04:45] <marex-cloud> On boot, U-Boot parses the DT, and calls the uart driver bind function, so the driver is bound (at this point, the hardware is not initialized)
[14:04:48] <jo0nas> and reset USB
[14:05:16] <jo0nas> before I interfere, it says "starting USB..."
[14:05:18] <marex-cloud> So when someone calls some print function , only then U-Boot initializes the uart hardware
[14:05:49] <marex-cloud> If the uart depends e.g. on clock, U-Boot might init clock hardware too, and so on
[14:06:17] <marex-cloud> Same for USB, since USB usually isn't needed to boot, U-Boot has no reason to init it
[14:06:50] <marex-cloud> But if you, as a user, need it, you can init it via the command line -- with usb reset/usb start
[14:07:14] <marex-cloud> See 'dm tree' command output, it shows you probed and bound drivers
[14:09:34] <marex-cloud> And mind you, while usb reset scans the bus , it again only binds the usb device drivers , it doesn't init those devices until you use them (e.g. with => load ... usb ... To load file from a stick or => setenv stdin to read from usb keyboard)
[14:09:41] <jo0nas> printenv includes this: preboot=usb start
[14:10:04] <marex-cloud> Right, that starts usb before the autoboot
[14:10:35] <marex-cloud> That should detect your keyboard, or doesn't it?
[14:10:41] <jo0nas> nope
[14:11:38] <marex-cloud> Try setenv preboot 'usb start ; usb tree ; usb reset ; usb tree' ; saveenv
[14:11:56] <marex-cloud> Then power cycle and see whether those two usb trees differ somehow
[14:12:15] <jo0nas> u-boot outputs "starting USB..." (which I guess corresponds with that "preboot=usb start"), then does a countdown - but I cannot interrupt the countdown using Teres-I keyboard but instead have to use serial
[14:12:33] <marex-cloud> Ah
[14:13:05] <marex-cloud> Try setenv preboot 'usb start ; usb tree ; coninfo ; usb reset ; usb tree ; coninfo' ; saveenv
[14:13:20] <marex-cloud> That would also print info about registered console devices
[14:13:21] <jo0nas> I don't think I can do saveenv on this setup - as I understand that only works with vfat partition on Allwinner boards
[14:13:33] <marex-cloud> And you can even add 'dm tree' after each coninfo
[14:13:54] <marex-cloud> jo0nas: can you adjust the preboot variable somehow?
[14:14:02] <jo0nas> ...but I can change my bootscr
[14:14:22] <jo0nas> ...but that loads _after_ preboot, right?
[14:14:36] <marex-cloud> I don't know , it depends on the env
[14:14:38] <marex-cloud> Probably
[14:14:57] <marex-cloud> Likely
[14:15:34] <jo0nas> I suspect this is where I wasted quite some time in the spring: Trying various settings of preboot= but applying it only via bootscr which is loaded _after_ preboot
[14:16:13] <jo0nas> ...and then - evidently - I forgot to test simply typing "usb reset" on the interactive commandline
[14:16:27] <jo0nas> ...because my end goal was to have it automated
[14:16:48] <marex-cloud> ;)
[14:18:38] <marex-cloud> But if usb start doesn't work properly in preboot, then you might need the pgood delay
[14:19:44] <jo0nas> I will try play with that
[15:06:46] <Marex> jo0nas: maybe you can rebuild the u-boot binary
[15:06:58] <Marex> jo0nas: then you can replace the preboot
[19:53:25] <jo0nas> U-Boot 2019.10-rc2-00001-gdf33f86468 (i.e. HEAD as mainline) boots fine on Teres-I, but keyboard doesn't work - neither when calling "usb reset" interactively
[19:55:22] <jo0nas> possibly related: Both initially and at usb reset is emitted this: USB device not accepting new address (error=2)
[19:57:33] <jo0nas> hmm - doing "usb stop", pausing for a few secs, then "usb start" I don't get above error and it says "scanning bus usb@1c1b000 for devices... 5 USB Device(s) found" (normally it finds only 4 devices)
[19:57:45] <jo0nas> ...but keyboard still dead
[20:03:33] <marex-cloud> jo0nas: set the pgood delay , saveenv , reset
[20:03:42] <marex-cloud> That might make usb start work
[20:03:53] <marex-cloud> Also, what does usb tree print?
[20:41:29] <jo0nas> usb tree lists controller, builtin hub, a plugged in ethernet NIC, and builtin camera
[20:44:31] <jo0nas> setenv usb_pgood_delay 2000 ; usb reset activates keyboard
[20:45:11] <jo0nas> usb tree now lists keyboard, and (more convincingly) typing on the keyboard is reflected in console
[20:49:11] <jo0nas> U-Boot 2019.07+dfsg-1 also activates keyboard with "setenv usb_pgood_delay 2000 ; usb reset" (at first attempt - after several failed "usb reset")
[20:50:46] <marex-cloud> jo0nas: increase the delay maybe?
[20:51:03] <marex-cloud> Oh, so the 2s delay helps
[20:51:46] <marex-cloud> jo0nas: well add the pgood delay and see if the usb start in $preboot also inits the keyboard
[20:55:40] <jo0nas> hmm - now I test U-Boot SPL 2019.01+dfsg-7 (i.e. stable Debian buster) and a simple "usb reset" works - tested 3 times with power-cycle in-between
[20:56:02] <jo0nas> ...so now I start to distrust if pgood was even needed, or I was just unlucky
[20:57:39] <jo0nas> I mean, I had _one_ success with pgood after 3-4 failed "usb-reset", all within same session - I have not tested multiple power-cycled sessions with or without pgood on u-boot 2019.07+dfsg-1 (a.k.a. unstable Debian sid)
[21:02:52] <jo0nas> I guess it doesn't really matter how frequent "usb reset" versus "setenv usb_pgood_delay 2000 ; usb reset" succeeds in _interactive_ testes if my goal is to have _automated_ use working: What is needed then is adding a delay and if pgood can do that then fine
[21:03:25] <jo0nas> ...I mean, then it doesn't matter if some releases of U_boot _also_ works with different kinds of delay
[21:04:14] <jo0nas> ACTION tries build Debian-forked U-boot with changed preboot entry
[21:05:43] <jo0nas> marex-cloud: sorry if that's what you've said all along :-/
[21:12:27] <marex-cloud> jo0nas: vbus might remain on since the first usb start in $preboot, so any subsequent usb reset would likely succeed
[21:14:16] <jo0nas> well, it didn't when I tested (in _one_ session) with U-boot 2019.07
[21:15:23] <marex-cloud> You measured the vbus? Ok
[21:15:56] <jo0nas> I did not measure vbus
[21:16:06] <jo0nas> I did not succeed
[21:18:13] <jo0nas> what I did was boot once with 2019.07, interrupt countdown, keyboard dead, "usb reset", keyboard dead, repeat 3-4 times and still dead, then "setenv usb_pgood_delay 2000 ; usb reset" and keyboard went live
[21:22:33] <jo0nas> correction: 2019.07 is not in Debian sid but in Debian experimental
[21:47:03] <Marex> jo0nas: but doesn't the 2019.07 have 'usb start' in $preboot ?
[21:48:02] <Marex> jo0nas: if you can, patch the preboot to read something like "usb start ; usb tree ; dm tree ; coninfo" , see what the output is across a couple of power cycles
[21:48:29] <Marex> jo0nas: then add "usb_pgood_delay=2000" to the env and repeat ^, if that changes anything , that's probably the fix too
[21:48:53] <Marex> presumably the keyboard would come up right after the 'usb start' in $preboot
[21:48:58] <Marex> if not, well, there's another problem
IRC #olimex 2019-08-17
[03:59:57] <xcko> force pushed a couple changes, basically just attempted to take the SetupKeyboard() in KeyboardMouse.c from the olimex repo and add it the the matrix_init_kb() in qmk_firmware but wasn't successful in doing anything. I need a better debugging setup to keep digging here, I'm just shooting in the dark hoping I get the keyboard init code right[12:46:11] <marex-cloud> xcko: U-Boot and USB keyboard problems?
[12:46:43] <marex-cloud> Is that mainline U-Boot or some hacked up vendor fork?
[12:47:05] <jo0nas> marex-cloud: Mainline u-boot fails to detect Teres-I keyboard
[12:47:16] <marex-cloud> Fails how?
[12:47:30] <marex-cloud> Didn't know mainline U-Boot supported the board
[12:48:01] <jo0nas> It does since ~May when I pushed some patches
[12:48:11] <marex-cloud> Ah good
[12:49:12] <jo0nas> marex-cloud: do you have access to the backlog of this room? Then please read backlog, it should explain how it fails
[12:50:30] <marex-cloud> I don't see the board in mainline , what's the DT file name?
[12:51:17] <marex-cloud> jo0nas: is that the internal keyboard that has issues?
[12:51:21] <jo0nas> configs/teres_i_defconfig
[12:52:03] <marex-cloud> jo0nas: I just recall someone had issues with some weird keyboard on rpi recently, there were even some patches posted, but the keyboard they used was some total broken trash
[12:52:09] <jo0nas> the theory is that the keyboard first presents itself as something else than a keyboard for a few seconds, and the u-boot driver fails to handle that (even if later reset)
[12:53:23] <marex-cloud> Something else?
[12:53:24] <jo0nas> yes it is the Teres-I keyboard - as backlog indicates, plugging in another USB-based keyboard gets recognized by u-boot driver
[12:53:55] <jo0nas> did you read backlog?
[12:54:00] <marex-cloud> No
[12:55:23] <marex-cloud> Just saw that U-Boot might have a bug in USB hid code, so I figured I might ask what's going on
[12:56:09] <jo0nas> you're welcome!
[12:56:12] <marex-cloud> There's an environment variable to keep vbus on for longer before probing the USB bus
[12:56:48] <marex-cloud> So if your keyboard needs to be powered up for a bit before it can be correctly recognized, that might help?
[12:56:51] <jo0nas> I tried that without success (but I might be doing something wrong - please do retry!)
[12:57:16] <marex-cloud> I don't have the board, I just maintain the USB in U-Boot
[12:57:32] <jo0nas> also, I suspect if delay would help then reset would work too
[12:57:35] <jo0nas> ah
[12:58:10] <jo0nas> so you offer expert insight to the u-boot driver - awesome!
[12:58:24] <marex-cloud> Ah, here it is
[12:59:00] <marex-cloud> setenv usb_pgood_delay 2000 ; usb reset
[12:59:04] <marex-cloud> Try that ^
[12:59:28] <jo0nas> ACTION pulls out his Teres-I...
[12:59:53] <marex-cloud> That will turn on the vbus , wait 2 seconds , the probe the bus
[13:01:37] <marex-cloud> Also look at https://patchwork.ozlabs.org/project/uboot/list/?series=123624
[13:01:57] <marex-cloud> But that applied to dwc2, so I dunno if that affects you too
[13:02:35] <jo0nas> thanks - still setting up the laptop (or rather, borrowing the laptop from my partner - I managed to break the screen on my own)
[13:03:30] <marex-cloud> No stress
[13:03:59] <jo0nas> :-)
[13:04:24] <jo0nas> ACTION excited there's hope to get this fixed!
[13:05:27] <jo0nas> that keyboard issue is possibly the last annoying detail blocking my recomming the Teres-I for my mom and others less technically interested
[13:05:51] <jo0nas> recommending*
[13:08:06] <marex-cloud> GPU?
[13:08:46] <jo0nas> not crucial for my needs
[13:09:00] <jo0nas> ...but certainly nice to have
[13:09:37] <jo0nas> ACTION does not equate non-tech users with GNOME, but am content with Xfce
[13:11:15] <marex-cloud> As the screens become bigger, doing composition with CPU is becoming a problem. Plus browsers use gpu for composition extensively
[13:12:00] <marex-cloud> But with Mali Txx, panfrost might soon be an option
[13:12:06] <jo0nas> indeed
[13:25:43] <jo0nas> whoah - that worked!
[13:27:00] <jo0nas> I guess I can then compare with include/configs/nitrogen6x.h for a patch to mainline U-boot
[13:27:07] <jo0nas> thanks a lot, marex-cloud!
[13:28:16] <jo0nas> uhhh, no
[13:28:26] <marex-cloud> Heh
[13:29:31] <jo0nas> I was thrown into ramfs shell - that's where keyboard worked
[13:29:43] <jo0nas> initramfs, I mean
[13:29:55] <jo0nas> still no working keyboard in u-boot
[13:30:22] <marex-cloud> So what does usb reset print?
[13:30:37] <marex-cloud> With that pgood delay set that is
[13:31:02] <jo0nas> let me find my serial cable to inspect this properly - it was rolling by too quickly
[13:33:23] <marex-cloud> jo0nas: no stress, slow down, that always helps
[13:35:16] <jo0nas> keyboard works!
[13:35:59] <marex-cloud> jo0nas: even after full power cycle?
[13:36:17] <jo0nas> interrupting boot from serial port, setting the variable, resetting USB - then keyboard works
[13:36:26] <marex-cloud> jo0nas: is that with or without the pgood delay?
[13:36:27] <marex-cloud> Oh
[13:36:50] <marex-cloud> And , after a power cycle, without the pgood delay, it does not?
[13:37:29] <jo0nas> power-cycle, repeating the voodoo, keyboard works
[13:38:05] <jo0nas> oh!
[13:38:22] <jo0nas> power-cycle, replacing voodoo with simple "usb reset", keyboard works
[13:38:53] <jo0nas> this is a newer u-boot than the one I fought with in the spring - perhaps you fixed it since then?
[13:39:27] <jo0nas> this is U-Boot 2019.01+dfsg-7 (from Debian sid)
[13:40:32] <jo0nas> ACTION goes to test with older U-boot in Debian buster (and grabs some breakfast while at it)
[13:45:22] <marex-cloud> jo0nas: uh, try U-Boot master please ;-)
[13:45:57] <marex-cloud> We're at 2019.10-rc2 already, although I guess vagrantc isn't gonna update the U-Boot in debian stable for obvious reasons
[13:46:41] <jo0nas> works in U-Boot 2019.01+dfsg-7 as well
[13:48:12] <jo0nas> vagrantc is quite hesitant to deviate from upstream, but can be convinced to carry reasonably-small backports - as he did for the Teres-I patches that I got into mainline for 2019.4 which is also included in 2019.01+dfsg-7
[13:49:44] <jo0nas> uhhh, wait: I just realize now that I am talking about exact same version for buster and sid - gotta be my mistake in how I make my images...
[13:50:35] <jo0nas> marex-cloud: Yes, I do understand that from a development POV I should work on HEAD of mainline U-boot
[13:51:19] <jo0nas> ...but quite interesting to me is that this works even with the older U-boot in stable Debian (needs only a "usb reset")
[13:51:56] <marex-cloud> jo0nas: would be at least good to test mainline here and there, to see if it still works
[13:52:31] <marex-cloud> jo0nas: so you can now somehow install regular debian on the laptop and it just works? That's nice
[13:53:14] <jo0nas> exactly!
[13:54:28] <jo0nas> yes, part of my pushing those patches for Teres-I to mainline U-boot was also that I added my name as maintainer - so I should certainly test from time to time that it still works - regardless of Debian release cycle
[13:54:56] <marex-cloud> jo0nas: so what's the story with the USB? It just works now?
[13:55:11] <marex-cloud> Why didn't it work before?
[13:55:20] <jo0nas> requires "usb reset" - doesn't work otherwise
[13:56:31] <jo0nas> possibly this worked for some time and what I haven't been able to make work is having that "usb reset" be part of the builtin code
[13:57:45] <jo0nas> ...and if that is true, then possibly that's because I really need to wait and then do reset (my manually intervening on serial port takes more than 2 seconds)
[13:58:08] <marex-cloud> Hold on
[13:58:10] <jo0nas> makes sense?
[13:58:41] <marex-cloud> You always have to do usb reset (or usb start), otherwise the bus isn't probed and the keyboard won't be found and registered
[13:58:49] <jo0nas> oh
[13:59:13] <marex-cloud> There's no automatic detection of USB peripherals, like in Linux
[13:59:26] <marex-cloud> It's all on demand
[14:00:03] <marex-cloud> So if you need USB ( or if the bus configuration changed somehow, e.g. you plugged something in ) , do usb reset
[14:00:24] <jo0nas> so "CONFIG_USB_EHCI_HCD=y" only builds the driver, doesn't ensure it is loaded?
[14:01:11] <marex-cloud> The driver is bound , so U-Boot driver model instantiates the controller driver on boot
[14:01:34] <marex-cloud> But only if the USB is needed is the controller initialized and the bus scanned
[14:01:55] <jo0nas> not sure what that means
[14:01:58] <marex-cloud> It's to ensure the boot is as fast as possible, without initializing useless stuff
[14:02:14] <marex-cloud> If you need something, you need to say so
[14:02:25] <jo0nas> in config?
[14:02:43] <jo0nas> uh, that was ambiguous
[14:02:50] <marex-cloud> On the command line (orn through dependencies between drivers)
[14:02:55] <jo0nas> by declaring env vars?
[14:03:18] <marex-cloud> All right, let's try again
[14:03:36] <marex-cloud> So to reach U-Boot command line, you only need serial console, right?
[14:04:00] <jo0nas> correct
[14:04:01] <marex-cloud> Ok, to get serial console, the uart driver must be compiled in
[14:04:37] <jo0nas> USB gets loaded automatically, yes
[14:04:44] <jo0nas> and then I interrrupt the countdown
[14:04:45] <marex-cloud> On boot, U-Boot parses the DT, and calls the uart driver bind function, so the driver is bound (at this point, the hardware is not initialized)
[14:04:48] <jo0nas> and reset USB
[14:05:16] <jo0nas> before I interfere, it says "starting USB..."
[14:05:18] <marex-cloud> So when someone calls some print function , only then U-Boot initializes the uart hardware
[14:05:49] <marex-cloud> If the uart depends e.g. on clock, U-Boot might init clock hardware too, and so on
[14:06:17] <marex-cloud> Same for USB, since USB usually isn't needed to boot, U-Boot has no reason to init it
[14:06:50] <marex-cloud> But if you, as a user, need it, you can init it via the command line -- with usb reset/usb start
[14:07:14] <marex-cloud> See 'dm tree' command output, it shows you probed and bound drivers
[14:09:34] <marex-cloud> And mind you, while usb reset scans the bus , it again only binds the usb device drivers , it doesn't init those devices until you use them (e.g. with => load ... usb ... To load file from a stick or => setenv stdin to read from usb keyboard)
[14:09:41] <jo0nas> printenv includes this: preboot=usb start
[14:10:04] <marex-cloud> Right, that starts usb before the autoboot
[14:10:35] <marex-cloud> That should detect your keyboard, or doesn't it?
[14:10:41] <jo0nas> nope
[14:11:38] <marex-cloud> Try setenv preboot 'usb start ; usb tree ; usb reset ; usb tree' ; saveenv
[14:11:56] <marex-cloud> Then power cycle and see whether those two usb trees differ somehow
[14:12:15] <jo0nas> u-boot outputs "starting USB..." (which I guess corresponds with that "preboot=usb start"), then does a countdown - but I cannot interrupt the countdown using Teres-I keyboard but instead have to use serial
[14:12:33] <marex-cloud> Ah
[14:13:05] <marex-cloud> Try setenv preboot 'usb start ; usb tree ; coninfo ; usb reset ; usb tree ; coninfo' ; saveenv
[14:13:20] <marex-cloud> That would also print info about registered console devices
[14:13:21] <jo0nas> I don't think I can do saveenv on this setup - as I understand that only works with vfat partition on Allwinner boards
[14:13:33] <marex-cloud> And you can even add 'dm tree' after each coninfo
[14:13:54] <marex-cloud> jo0nas: can you adjust the preboot variable somehow?
[14:14:02] <jo0nas> ...but I can change my bootscr
[14:14:22] <jo0nas> ...but that loads _after_ preboot, right?
[14:14:36] <marex-cloud> I don't know , it depends on the env
[14:14:38] <marex-cloud> Probably
[14:14:57] <marex-cloud> Likely
[14:15:34] <jo0nas> I suspect this is where I wasted quite some time in the spring: Trying various settings of preboot= but applying it only via bootscr which is loaded _after_ preboot
[14:16:13] <jo0nas> ...and then - evidently - I forgot to test simply typing "usb reset" on the interactive commandline
[14:16:27] <jo0nas> ...because my end goal was to have it automated
[14:16:48] <marex-cloud> ;)
[14:18:38] <marex-cloud> But if usb start doesn't work properly in preboot, then you might need the pgood delay
[14:19:44] <jo0nas> I will try play with that
[15:06:46] <Marex> jo0nas: maybe you can rebuild the u-boot binary
[15:06:58] <Marex> jo0nas: then you can replace the preboot
[19:53:25] <jo0nas> U-Boot 2019.10-rc2-00001-gdf33f86468 (i.e. HEAD as mainline) boots fine on Teres-I, but keyboard doesn't work - neither when calling "usb reset" interactively
[19:55:22] <jo0nas> possibly related: Both initially and at usb reset is emitted this: USB device not accepting new address (error=2)
[19:57:33] <jo0nas> hmm - doing "usb stop", pausing for a few secs, then "usb start" I don't get above error and it says "scanning bus usb@1c1b000 for devices... 5 USB Device(s) found" (normally it finds only 4 devices)
[19:57:45] <jo0nas> ...but keyboard still dead
[20:03:33] <marex-cloud> jo0nas: set the pgood delay , saveenv , reset
[20:03:42] <marex-cloud> That might make usb start work
[20:03:53] <marex-cloud> Also, what does usb tree print?
[20:41:29] <jo0nas> usb tree lists controller, builtin hub, a plugged in ethernet NIC, and builtin camera
[20:44:31] <jo0nas> setenv usb_pgood_delay 2000 ; usb reset activates keyboard
[20:45:11] <jo0nas> usb tree now lists keyboard, and (more convincingly) typing on the keyboard is reflected in console
[20:49:11] <jo0nas> U-Boot 2019.07+dfsg-1 also activates keyboard with "setenv usb_pgood_delay 2000 ; usb reset" (at first attempt - after several failed "usb reset")
[20:50:46] <marex-cloud> jo0nas: increase the delay maybe?
[20:51:03] <marex-cloud> Oh, so the 2s delay helps
[20:51:46] <marex-cloud> jo0nas: well add the pgood delay and see if the usb start in $preboot also inits the keyboard
[20:55:40] <jo0nas> hmm - now I test U-Boot SPL 2019.01+dfsg-7 (i.e. stable Debian buster) and a simple "usb reset" works - tested 3 times with power-cycle in-between
[20:56:02] <jo0nas> ...so now I start to distrust if pgood was even needed, or I was just unlucky
[20:57:39] <jo0nas> I mean, I had _one_ success with pgood after 3-4 failed "usb-reset", all within same session - I have not tested multiple power-cycled sessions with or without pgood on u-boot 2019.07+dfsg-1 (a.k.a. unstable Debian sid)
[21:02:52] <jo0nas> I guess it doesn't really matter how frequent "usb reset" versus "setenv usb_pgood_delay 2000 ; usb reset" succeeds in _interactive_ testes if my goal is to have _automated_ use working: What is needed then is adding a delay and if pgood can do that then fine
[21:03:25] <jo0nas> ...I mean, then it doesn't matter if some releases of U_boot _also_ works with different kinds of delay
[21:04:14] <jo0nas> ACTION tries build Debian-forked U-boot with changed preboot entry
[21:05:43] <jo0nas> marex-cloud: sorry if that's what you've said all along :-/
[21:12:27] <marex-cloud> jo0nas: vbus might remain on since the first usb start in $preboot, so any subsequent usb reset would likely succeed
[21:14:16] <jo0nas> well, it didn't when I tested (in _one_ session) with U-boot 2019.07
[21:15:23] <marex-cloud> You measured the vbus? Ok
[21:15:56] <jo0nas> I did not measure vbus
[21:16:06] <jo0nas> I did not succeed
[21:18:13] <jo0nas> what I did was boot once with 2019.07, interrupt countdown, keyboard dead, "usb reset", keyboard dead, repeat 3-4 times and still dead, then "setenv usb_pgood_delay 2000 ; usb reset" and keyboard went live
[21:22:33] <jo0nas> correction: 2019.07 is not in Debian sid but in Debian experimental
[21:47:03] <Marex> jo0nas: but doesn't the 2019.07 have 'usb start' in $preboot ?
[21:48:02] <Marex> jo0nas: if you can, patch the preboot to read something like "usb start ; usb tree ; dm tree ; coninfo" , see what the output is across a couple of power cycles
[21:48:29] <Marex> jo0nas: then add "usb_pgood_delay=2000" to the env and repeat ^, if that changes anything , that's probably the fix too
[21:48:53] <Marex> presumably the keyboard would come up right after the 'usb start' in $preboot
[21:48:58] <Marex> if not, well, there's another problem
