≡
[00:37:09] <jo0nas> xcko: current status is that the builtin keyboard is not functional during u-boot but works fine in Linux
[00:37:40] <jo0nas> if you need keyboard during u-boot, plug in an external keyboard
[00:38:14] <xcko> yeah, right now the keyboard isn't picked up correctly in OpenBSD so I'm curious what kind of quirks it may need
[00:39:29] <xcko> I thought it might be related, or at least I might learn more about how the keyboard works. Right now the umodem driver picks up the keyboard on OpenBSD. would you mind giving a pastebin of `lsusb -v`?
[00:44:03] <Thra11> jo0nas: I've noticed that this is the case. Do we know exactly why the internal keyboard doesn't work in u-boot?
[00:45:37] <Thra11> I was wondering whether it isn't powered until later or something? Or maybe its USB implementation is 'quirky', such that u-boot can't talk to it.
[00:46:27] <xcko> "Known broken: - Internal keyboard (seems to be because the keyboard firmware loads a bootloader first, and then disconnects bootloader and connect real keyboard). External ones connected to the USB port work fine."
[00:46:37] <xcko> from u-boot git log
[00:46:59] <Thra11> xcko: Cool. Thanks
[00:47:24] <xcko> I'm curious as well what this bootloader is, if it needs to be communicated with, or needs extra setup by the kernel
[00:48:49] <Thra11> I wonder if the bootloader supports USB communications in order to receive firmware updates or something.
[00:49:29] <Thra11> (So that you can reflash the firmware even if you've flashed it with broken firmware)
[00:50:05] <xcko> I know the keyboard can be flashed from userspace, which implies two interfaces at least. So perhaps OpenBSD is just picking up the programming interface and not the usb keyboard interface
[00:50:41] <xcko> There are some details on programming the keyboard firmware from userspace in the olimex/diy-laptop github repo
[00:56:24] <Thra11> Appears to be a modified version of the teensy bootloader.
[01:15:22] <xcko> it's gotta boot just on power, but so do other usb keyboards. I don't understand why it needs to be treated differently... typical usb keyboards don't show the bootloader connecting and disconnecting?
[01:16:25] <Thra11> Hmmm. It explains how to start the bootloader, but I haven't yet found anything explaining how it goes from bootloader to application code
[01:16:38] <xcko> where do you see that?
[01:17:30] <Thra11> In the github repo, TERES-KBD-RELEASE/BootLoaderHID/BootloaderHID.txt
[01:18:28] <Thra11> ground HWB, then momentarily ground RESET to start the bootloader
[01:19:15] <Thra11> I wonder if starting the application (keyboard) is just a case of grounding RESET with HWB pulled high?
[01:19:45] <Thra11> or at least not grounded
[01:21:35] <Thra11> Or its possible that once the bootloader has enumerated as a USB HID, you can politely ask it to go away and run something else instead
[01:23:47] <Thra11> Or the bootloader might time out after a while
[01:26:41] <xcko> I hit Fn+Tux+Esc and had output in dmesg connecting and disconnecting an hid device so I think that may have been the boot process
[01:28:25] <Thra11> That's part of the flashing procedure, isn't it?
[01:30:10] <xcko> yeah in hid_bootloader_cli.c it loops waiting for the bootloader and that key combo seems to be how to start ip
[01:30:14] <xcko> s/ip/it/
[01:39:01] <Thra11> Looks like the host can send it a COMMAND_STARTAPPLICATION via the USB interface. Presumably u-boot doesn't.
[01:42:03] <Thra11> Otherwise there's a timeout of ~2 seconds
[01:42:53] <Thra11> But maybe u-boot's already given up on it by then
[01:47:02] <xcko> I wonder if it's possible to send COMMAND_STARTAPPLICATION from the u-boot prompt. Does u-boot even support hotplugging?
[01:47:50] <Thra11> Not sure
[01:49:56] <Thra11> If it doesn't, that might explain why the 2s timeout still doesn't allow it to work after 2s
[01:50:32] <Thra11> (assuming u-boot's boot delay is long enough)
[01:57:29] <xcko> well if I stop the autoboot at the u-boot prompt (version 2019.07) and then plug in a usb keyboard, I see no output when hitting keys. implying no hotplugging imo
[02:08:29] <xcko> though usb reset can be called to get an external usb keyboard noticed. Looking through u-boot's menuconfig it seems doable to start the keyboard during u-boot just with a correct config. I wonder if there are other devices that have a similar keyboard setup as the teres that do work with u-boot?
[02:11:04] <xcko> so how come after the teres boots up, running `usb reset` to scan for new devices at the u-boot prompt works for external usb keyboards but not the internal teres keyboard?
[02:17:39] <xcko> I'm starting to suspect that perhaps the program on the teensy that is run after the bootloader doesn't identify itself correctly and so u-boot and OpenBSD don't recognize it but linux is flexible enough to figure it out
[02:17:51] <xcko> s/teensy/avr
[02:34:09] <xcko> or the issue is this "After loading an application, it is not run automatically on startup." in the Known Issues section of the .txt file. Fn+Tux+Esc will restart the bootloader, which correctly identifies as usb hid in u-boot (run usb reset at the u-boot prompt immediately after the key combo to see), and then loads the application (the keyboard+trackpad) but does not start it.
[02:35:19] <xcko> those are my thoughts, either the applicaton loaded by the bootloader does not correctly identify itself as usb-hid and linux has a workaround for it, or the application does not start running until linux starts it correctly.
[03:12:10] <xcko> diego71: still got that forked teres kbd repo somewhere?
[09:20:45] <leon-anavi> hi
IRC #olimex 2019-08-15
[00:02:27] <xcko> so for the teres laptop, there is a note in u-boot about how the internal keyboard does not work at u-boot because the internal keyboard needs to boot, then reattaches as a usb device. What is the boot process? Does it need to be started by the OS? is it automatic?[00:37:09] <jo0nas> xcko: current status is that the builtin keyboard is not functional during u-boot but works fine in Linux
[00:37:40] <jo0nas> if you need keyboard during u-boot, plug in an external keyboard
[00:38:14] <xcko> yeah, right now the keyboard isn't picked up correctly in OpenBSD so I'm curious what kind of quirks it may need
[00:39:29] <xcko> I thought it might be related, or at least I might learn more about how the keyboard works. Right now the umodem driver picks up the keyboard on OpenBSD. would you mind giving a pastebin of `lsusb -v`?
[00:44:03] <Thra11> jo0nas: I've noticed that this is the case. Do we know exactly why the internal keyboard doesn't work in u-boot?
[00:45:37] <Thra11> I was wondering whether it isn't powered until later or something? Or maybe its USB implementation is 'quirky', such that u-boot can't talk to it.
[00:46:27] <xcko> "Known broken: - Internal keyboard (seems to be because the keyboard firmware loads a bootloader first, and then disconnects bootloader and connect real keyboard). External ones connected to the USB port work fine."
[00:46:37] <xcko> from u-boot git log
[00:46:59] <Thra11> xcko: Cool. Thanks
[00:47:24] <xcko> I'm curious as well what this bootloader is, if it needs to be communicated with, or needs extra setup by the kernel
[00:48:49] <Thra11> I wonder if the bootloader supports USB communications in order to receive firmware updates or something.
[00:49:29] <Thra11> (So that you can reflash the firmware even if you've flashed it with broken firmware)
[00:50:05] <xcko> I know the keyboard can be flashed from userspace, which implies two interfaces at least. So perhaps OpenBSD is just picking up the programming interface and not the usb keyboard interface
[00:50:41] <xcko> There are some details on programming the keyboard firmware from userspace in the olimex/diy-laptop github repo
[00:56:24] <Thra11> Appears to be a modified version of the teensy bootloader.
[01:15:22] <xcko> it's gotta boot just on power, but so do other usb keyboards. I don't understand why it needs to be treated differently... typical usb keyboards don't show the bootloader connecting and disconnecting?
[01:16:25] <Thra11> Hmmm. It explains how to start the bootloader, but I haven't yet found anything explaining how it goes from bootloader to application code
[01:16:38] <xcko> where do you see that?
[01:17:30] <Thra11> In the github repo, TERES-KBD-RELEASE/BootLoaderHID/BootloaderHID.txt
[01:18:28] <Thra11> ground HWB, then momentarily ground RESET to start the bootloader
[01:19:15] <Thra11> I wonder if starting the application (keyboard) is just a case of grounding RESET with HWB pulled high?
[01:19:45] <Thra11> or at least not grounded
[01:21:35] <Thra11> Or its possible that once the bootloader has enumerated as a USB HID, you can politely ask it to go away and run something else instead
[01:23:47] <Thra11> Or the bootloader might time out after a while
[01:26:41] <xcko> I hit Fn+Tux+Esc and had output in dmesg connecting and disconnecting an hid device so I think that may have been the boot process
[01:28:25] <Thra11> That's part of the flashing procedure, isn't it?
[01:30:10] <xcko> yeah in hid_bootloader_cli.c it loops waiting for the bootloader and that key combo seems to be how to start ip
[01:30:14] <xcko> s/ip/it/
[01:39:01] <Thra11> Looks like the host can send it a COMMAND_STARTAPPLICATION via the USB interface. Presumably u-boot doesn't.
[01:42:03] <Thra11> Otherwise there's a timeout of ~2 seconds
[01:42:53] <Thra11> But maybe u-boot's already given up on it by then
[01:47:02] <xcko> I wonder if it's possible to send COMMAND_STARTAPPLICATION from the u-boot prompt. Does u-boot even support hotplugging?
[01:47:50] <Thra11> Not sure
[01:49:56] <Thra11> If it doesn't, that might explain why the 2s timeout still doesn't allow it to work after 2s
[01:50:32] <Thra11> (assuming u-boot's boot delay is long enough)
[01:57:29] <xcko> well if I stop the autoboot at the u-boot prompt (version 2019.07) and then plug in a usb keyboard, I see no output when hitting keys. implying no hotplugging imo
[02:08:29] <xcko> though usb reset can be called to get an external usb keyboard noticed. Looking through u-boot's menuconfig it seems doable to start the keyboard during u-boot just with a correct config. I wonder if there are other devices that have a similar keyboard setup as the teres that do work with u-boot?
[02:11:04] <xcko> so how come after the teres boots up, running `usb reset` to scan for new devices at the u-boot prompt works for external usb keyboards but not the internal teres keyboard?
[02:17:39] <xcko> I'm starting to suspect that perhaps the program on the teensy that is run after the bootloader doesn't identify itself correctly and so u-boot and OpenBSD don't recognize it but linux is flexible enough to figure it out
[02:17:51] <xcko> s/teensy/avr
[02:34:09] <xcko> or the issue is this "After loading an application, it is not run automatically on startup." in the Known Issues section of the .txt file. Fn+Tux+Esc will restart the bootloader, which correctly identifies as usb hid in u-boot (run usb reset at the u-boot prompt immediately after the key combo to see), and then loads the application (the keyboard+trackpad) but does not start it.
[02:35:19] <xcko> those are my thoughts, either the applicaton loaded by the bootloader does not correctly identify itself as usb-hid and linux has a workaround for it, or the application does not start running until linux starts it correctly.
[03:12:10] <xcko> diego71: still got that forked teres kbd repo somewhere?
[09:20:45] <leon-anavi> hi
