≡
[10:19:46] <xcko> is INITIAL_USB_SCAN_DELAY the equivalent config option?
[12:23:33] <jo0nas> looks like CONFIG_INITIAL_USB_SCAN_DELAY is a sunxi-specific option which adds a delay _before_ powering up the USB hub, whereas environment option usb_pgood_delay adds a delay _after_ powering up the USB hub but before _probing_ for USB devices
[12:24:37] <jo0nas> seems to me the sensible thing to do for mainline U-Boot is to get rid of CONFIG_INITIAL_USB_SCAN_DELAY if usb_pgood_delay works equally well
[13:48:04] <jo0nas> marex, xcko_: CONFIG_INITIAL_USB_SCAN_DELAY won't work (probably because builtin keyboard draws power from USB hub) but I now have a working patchset for 2019.07 reliably enabling keyboard using usb_pgood_delay: https://salsa.debian.org/js/u-boot/tree/wip/teres-i/debian/patches/sunxi
[13:48:46] <jo0nas> now onto testing against Debian stable 2019.01 and then mainline 2019.10 :-)
[13:55:56] <Marex> jo0nas: arent you missing the usb_pgood_delay there ?
[13:56:06] <jo0nas> whoops - I just noticed same myself
[13:56:28] <jo0nas> yes, I forgot to update one of the patches to the actually working one :-P
[14:05:38] <jo0nas> marex: Have a look now
[14:07:26] <jo0nas> what also fooled me in the past is that setting CONFIG_PREBOOT alone is ignored - have to also set CONFIG_USE_PREBOOT (even if - confusing at least to me - sunxi devices already enable preboot internally without that flag)
[14:07:45] <Marex> jo0nas: you can add the usb_pgood_delay to default environment instead
[14:07:55] <jo0nas> how?
[14:08:30] <jo0nas> doable with CONFIG_* values?
[14:09:05] <Marex> jo0nas: in include/configs/<yourboard>.h
[14:09:16] <jo0nas> sunxi devices all share a common include file, so I cannot easily introduce a board tweak
[14:10:11] <Marex> oh
[14:11:22] <jo0nas> also, it seems to me the common style in U-Boot to declare configuration in include/<board>.defconfig, no?
[14:11:48] <Marex> jo0nas: the Kconfig migration is in progress, some options are not migrated over yet
[14:13:09] <jo0nas> you are USB maintainer, right? Perhaps sensible that you consider adopting and replacing that CONFIG_INITIAL_USB_SCAN_DELAY currently used only for sunxi devices and slightly differently (but, I suspect, equally fine for them to use your approach)
[14:14:31] <jo0nas> right, it is exactly due to the recent code changes that I have a clue at all of what seems to be the preferred style :-)
[14:14:59] <jo0nas> ACTION is new to (closely following development of) U-Boot
[14:15:17] <Marex> jo0nas: such delay should be described in DT I think
[14:17:48] <Marex> (that initial usb scan delay should I think be in DT)
[14:18:16] <Marex> in fact, the whole power handling should be converted to regulator framework, which already has facilities for pre- and post- enable delays, and those can be described correctly in DT
[14:18:23] <Marex> thus, no need for ad-hoc config option
[14:22:19] <jo0nas> ah
[14:33:27] <jo0nas> patchset works with (Debian-patched) 2019.01 as well!
[14:39:36] <Marex> jo0nas: nice
[14:39:39] <Marex> jo0nas: even across power cycles ?
[14:41:57] <jo0nas> yes
[14:44:21] <jo0nas> the laptop persistently enables the builtin keyboard - tested 4 power cycles now
[14:44:45] <Marex> good :)
[14:51:08] <Marex> jo0nas: do they still use this 16bit DRAM interface ? if so, that would likely seriously limit the bandwidth
[15:09:38] <jo0nas> sorry, I don't understand the question
[15:41:43] <Marex> jo0nas: well, I recall the teresI had some severely misdesigned DRAM bus
[15:41:50] <Marex> jo0nas: I think it was DDR3 x16
[15:41:58] <Marex> jo0nas: is that still the case ?
[15:51:45] <jo0nas> sorry I don't know that stuff
[15:52:38] <Marex> jo0nas: no worries
[15:52:43] <jo0nas> ACTION is surprised to be helpful in refining U-Boot for the Teres-I
[15:53:19] <Marex> jo0nas: it's good it works now
[15:54:17] <jo0nas> don't get me wrong: I am not being humble - I have 20 years experience as Debian Developer, but my experience is with perl, bash, make, and patch - I can _patch_ real programming code but am unlikely to be write "hello world" in them :-)
[15:56:11] <jo0nas> marex: How do I credit you in patch tags when proposing my patch to Mainline U-Boot?
[15:56:49] <jo0nas> your clueing me in on that usb_pgood_delay variable was crucial to solving this!
[15:57:21] <jo0nas> ACTION is drafting a patch for mainline U-Boot now
[16:15:37] <Marex> jo0nas: I dont really care about credit :)
[16:15:53] <Marex> jo0nas: I am happy debian user, so keep the good work up, thanks
[16:23:14] <jo0nas> :-)
[16:56:28] <jo0nas> hi dddddd - do I remember correctly that you have a Teres-I?
[16:57:16] <dddddd> that's right, jo0nas
[17:03:30] <jo0nas> I solved today the issue with builtin keyboard not loading under U-Boot: https://bugs.debian.org/935035
[17:04:01] <jo0nas> ACTION is working on patchset for mainline U-Boot now :-D
[17:06:07] <dddddd> oh, great... thanks for heads-up!
[17:07:39] <dddddd> I read something about delay in the logs, thanks Marex too!
[20:51:26] <jo0nas> dddddd: Did you manage to test GPU somehow?
[20:53:38] <jo0nas> I know that Lima support for OpenGL has been temporarily disabled in libgl1-mesa-dri (and related binary packages) but is expected to return from release 19.2 - but you mentioned alternative testing than via X11
[21:40:18] <marex-cloud> jo0nas: does that SoC have mali4xx ? I'd expect it to have Mali Txx, thus panfrost (not Lima)
[21:49:14] <jo0nas> marex: Yes, according to first line of https://linux-sunxi.org/A64
[21:49:32] <jo0nas> ...and kernel mentions lima
IRC #olimex 2019-08-18
[07:04:23] <xcko> U-Boot 2019.07. Interrupt autoboot with serial console, then run setenv usb_pgood_delay 2000; usb reset; then the keyboard is detected. saveenv does work for me (with a fat boot partition) and future reboots will show keyboard detected. Is there a part of u-boot's config to set usb_pgood_delay?[10:19:46] <xcko> is INITIAL_USB_SCAN_DELAY the equivalent config option?
[12:23:33] <jo0nas> looks like CONFIG_INITIAL_USB_SCAN_DELAY is a sunxi-specific option which adds a delay _before_ powering up the USB hub, whereas environment option usb_pgood_delay adds a delay _after_ powering up the USB hub but before _probing_ for USB devices
[12:24:37] <jo0nas> seems to me the sensible thing to do for mainline U-Boot is to get rid of CONFIG_INITIAL_USB_SCAN_DELAY if usb_pgood_delay works equally well
[13:48:04] <jo0nas> marex, xcko_: CONFIG_INITIAL_USB_SCAN_DELAY won't work (probably because builtin keyboard draws power from USB hub) but I now have a working patchset for 2019.07 reliably enabling keyboard using usb_pgood_delay: https://salsa.debian.org/js/u-boot/tree/wip/teres-i/debian/patches/sunxi
[13:48:46] <jo0nas> now onto testing against Debian stable 2019.01 and then mainline 2019.10 :-)
[13:55:56] <Marex> jo0nas: arent you missing the usb_pgood_delay there ?
[13:56:06] <jo0nas> whoops - I just noticed same myself
[13:56:28] <jo0nas> yes, I forgot to update one of the patches to the actually working one :-P
[14:05:38] <jo0nas> marex: Have a look now
[14:07:26] <jo0nas> what also fooled me in the past is that setting CONFIG_PREBOOT alone is ignored - have to also set CONFIG_USE_PREBOOT (even if - confusing at least to me - sunxi devices already enable preboot internally without that flag)
[14:07:45] <Marex> jo0nas: you can add the usb_pgood_delay to default environment instead
[14:07:55] <jo0nas> how?
[14:08:30] <jo0nas> doable with CONFIG_* values?
[14:09:05] <Marex> jo0nas: in include/configs/<yourboard>.h
[14:09:16] <jo0nas> sunxi devices all share a common include file, so I cannot easily introduce a board tweak
[14:10:11] <Marex> oh
[14:11:22] <jo0nas> also, it seems to me the common style in U-Boot to declare configuration in include/<board>.defconfig, no?
[14:11:48] <Marex> jo0nas: the Kconfig migration is in progress, some options are not migrated over yet
[14:13:09] <jo0nas> you are USB maintainer, right? Perhaps sensible that you consider adopting and replacing that CONFIG_INITIAL_USB_SCAN_DELAY currently used only for sunxi devices and slightly differently (but, I suspect, equally fine for them to use your approach)
[14:14:31] <jo0nas> right, it is exactly due to the recent code changes that I have a clue at all of what seems to be the preferred style :-)
[14:14:59] <jo0nas> ACTION is new to (closely following development of) U-Boot
[14:15:17] <Marex> jo0nas: such delay should be described in DT I think
[14:17:48] <Marex> (that initial usb scan delay should I think be in DT)
[14:18:16] <Marex> in fact, the whole power handling should be converted to regulator framework, which already has facilities for pre- and post- enable delays, and those can be described correctly in DT
[14:18:23] <Marex> thus, no need for ad-hoc config option
[14:22:19] <jo0nas> ah
[14:33:27] <jo0nas> patchset works with (Debian-patched) 2019.01 as well!
[14:39:36] <Marex> jo0nas: nice
[14:39:39] <Marex> jo0nas: even across power cycles ?
[14:41:57] <jo0nas> yes
[14:44:21] <jo0nas> the laptop persistently enables the builtin keyboard - tested 4 power cycles now
[14:44:45] <Marex> good :)
[14:51:08] <Marex> jo0nas: do they still use this 16bit DRAM interface ? if so, that would likely seriously limit the bandwidth
[15:09:38] <jo0nas> sorry, I don't understand the question
[15:41:43] <Marex> jo0nas: well, I recall the teresI had some severely misdesigned DRAM bus
[15:41:50] <Marex> jo0nas: I think it was DDR3 x16
[15:41:58] <Marex> jo0nas: is that still the case ?
[15:51:45] <jo0nas> sorry I don't know that stuff
[15:52:38] <Marex> jo0nas: no worries
[15:52:43] <jo0nas> ACTION is surprised to be helpful in refining U-Boot for the Teres-I
[15:53:19] <Marex> jo0nas: it's good it works now
[15:54:17] <jo0nas> don't get me wrong: I am not being humble - I have 20 years experience as Debian Developer, but my experience is with perl, bash, make, and patch - I can _patch_ real programming code but am unlikely to be write "hello world" in them :-)
[15:56:11] <jo0nas> marex: How do I credit you in patch tags when proposing my patch to Mainline U-Boot?
[15:56:49] <jo0nas> your clueing me in on that usb_pgood_delay variable was crucial to solving this!
[15:57:21] <jo0nas> ACTION is drafting a patch for mainline U-Boot now
[16:15:37] <Marex> jo0nas: I dont really care about credit :)
[16:15:53] <Marex> jo0nas: I am happy debian user, so keep the good work up, thanks
[16:23:14] <jo0nas> :-)
[16:56:28] <jo0nas> hi dddddd - do I remember correctly that you have a Teres-I?
[16:57:16] <dddddd> that's right, jo0nas
[17:03:30] <jo0nas> I solved today the issue with builtin keyboard not loading under U-Boot: https://bugs.debian.org/935035
[17:04:01] <jo0nas> ACTION is working on patchset for mainline U-Boot now :-D
[17:06:07] <dddddd> oh, great... thanks for heads-up!
[17:07:39] <dddddd> I read something about delay in the logs, thanks Marex too!
[20:51:26] <jo0nas> dddddd: Did you manage to test GPU somehow?
[20:53:38] <jo0nas> I know that Lima support for OpenGL has been temporarily disabled in libgl1-mesa-dri (and related binary packages) but is expected to return from release 19.2 - but you mentioned alternative testing than via X11
[21:40:18] <marex-cloud> jo0nas: does that SoC have mali4xx ? I'd expect it to have Mali Txx, thus panfrost (not Lima)
[21:49:14] <jo0nas> marex: Yes, according to first line of https://linux-sunxi.org/A64
[21:49:32] <jo0nas> ...and kernel mentions lima
