≡
[11:17:25] <jo0nas> that's too bad - I would love to be able to point to "proof" of your products being "legit"
[11:18:18] <jo0nas> ...and I think it affects some sales too - but I totally respect if your priorities are different
[11:20:12] <jo0nas> Tsvetan: I am currently working on pushing support for Teres-I into mainline u-boot - latest attemt is https://patchwork.ozlabs.org/patch/1088354/ with working backlight and USB driver, but the built-in keyboard fails to load
[11:21:10] <jo0nas> the actual work is not mine - what I have done is try piece together work of others, and nudge them to guide me when my builds fail to work
[11:22:15] <tbr> getting patches upstream can be hard work
[11:22:17] <jo0nas> Tsvetan: perhaps you could consider mentioning that mainlining work in a blog post - to potentially attract some attention to it from people skilled enough to get that keyboard problem solved
[11:23:29] <jo0nas> the patches has been adopted into Debian proper now - tracked at https://wiki.debian.org/InstallingDebianOn/Olimex/Teres-I#u-boot
[11:24:54] <jo0nas> possibly that working patchset will get included in Debian Buster (i.e. the next stable release) - tracked at https://tracker.debian.org/pkg/u-boot - we will know that in three days at best
[11:26:09] <jo0nas> tbr: yes, getting code to work and getting code aligned with every other related contemporary work are quite different challenges!
[11:28:47] <nedko> if atmel mcu representing the teres-1 the keyboard talks to u-boot via uart, no patches would be probably needed
[11:28:52] <nedko> no patches to u-boot
[11:31:35] <nedko> *the teres-1 keyboard
[11:37:23] <jo0nas> nedko: you mean if keyboard controller board is reprogrammed, or you mean current firmware can work in a different mode if u-boot is only listening differently?
[11:41:10] <nedko> jo0nas: either of them, hopefully the latter. i just say that uart hardware interface seems to be quite native for u-boot. and while i've not found time to tickle with the keyboard controller on my teres-1, i've programmed such mcu-s before and i know they had/ve uart modules on chip
[11:43:53] <jo0nas> that sounds interesting! I sure hope you can find some time some day to tinker with that. because it is too low-level for me to make sense of!
[11:45:24] <nedko> i have to check schematics, but i think it would invole rewiring of the 3.5mm uart debug to keyboard uart mcu, with some switching logic probably
[11:46:37] <jo0nas> ah ok, then I would prefer fixing the USB driver
[15:57:57] <jo0nas> Tsvetan: congratulations with your new Freedombox-branded device!
[17:36:49] <Tsvetan> jo0nas: it's not about different priorities we just work on 10 projects at same time, I really want to have some more time to may submit all the OSHW projects we have. I will blog about what you did :)
[17:37:36] <Tsvetan> jo0nas the FreedomBox-HSK probably will be also our first RYF certified product
[18:20:49] <jo0nas> cool - all of it: the amount of projects you do, intending to report all OSHW project, blogging about Teres-I u-boot mainling, and RYF certification \0/
[19:56:47] <jo0nas> Tsvetan: I bet it you offer a metal box for the OlinuXino A64 then that will raise sales among people wanting a more powerful/modern box than the Lime2 for FreedomBox
[22:26:17] <Antitrack> freedombox-branded device? which one?
[22:46:18] <xcko> I believe it's the one at the top of the olimex.com page
[22:48:31] <xcko> https://olimex.wordpress.com/2019/04/22/freedombox-your-private-box-of-freedom-for-decentralizing-the-internet-and-keeping-your-privacy-away-from-the-big-brother/
[22:49:00] <Antitrack> ok
IRC #olimex 2019-04-22
[11:06:44] <Tsvetan> jo0nas lot of OSHW products are not listed there :( no time to list all[11:17:25] <jo0nas> that's too bad - I would love to be able to point to "proof" of your products being "legit"
[11:18:18] <jo0nas> ...and I think it affects some sales too - but I totally respect if your priorities are different
[11:20:12] <jo0nas> Tsvetan: I am currently working on pushing support for Teres-I into mainline u-boot - latest attemt is https://patchwork.ozlabs.org/patch/1088354/ with working backlight and USB driver, but the built-in keyboard fails to load
[11:21:10] <jo0nas> the actual work is not mine - what I have done is try piece together work of others, and nudge them to guide me when my builds fail to work
[11:22:15] <tbr> getting patches upstream can be hard work
[11:22:17] <jo0nas> Tsvetan: perhaps you could consider mentioning that mainlining work in a blog post - to potentially attract some attention to it from people skilled enough to get that keyboard problem solved
[11:23:29] <jo0nas> the patches has been adopted into Debian proper now - tracked at https://wiki.debian.org/InstallingDebianOn/Olimex/Teres-I#u-boot
[11:24:54] <jo0nas> possibly that working patchset will get included in Debian Buster (i.e. the next stable release) - tracked at https://tracker.debian.org/pkg/u-boot - we will know that in three days at best
[11:26:09] <jo0nas> tbr: yes, getting code to work and getting code aligned with every other related contemporary work are quite different challenges!
[11:28:47] <nedko> if atmel mcu representing the teres-1 the keyboard talks to u-boot via uart, no patches would be probably needed
[11:28:52] <nedko> no patches to u-boot
[11:31:35] <nedko> *the teres-1 keyboard
[11:37:23] <jo0nas> nedko: you mean if keyboard controller board is reprogrammed, or you mean current firmware can work in a different mode if u-boot is only listening differently?
[11:41:10] <nedko> jo0nas: either of them, hopefully the latter. i just say that uart hardware interface seems to be quite native for u-boot. and while i've not found time to tickle with the keyboard controller on my teres-1, i've programmed such mcu-s before and i know they had/ve uart modules on chip
[11:43:53] <jo0nas> that sounds interesting! I sure hope you can find some time some day to tinker with that. because it is too low-level for me to make sense of!
[11:45:24] <nedko> i have to check schematics, but i think it would invole rewiring of the 3.5mm uart debug to keyboard uart mcu, with some switching logic probably
[11:46:37] <jo0nas> ah ok, then I would prefer fixing the USB driver
[15:57:57] <jo0nas> Tsvetan: congratulations with your new Freedombox-branded device!
[17:36:49] <Tsvetan> jo0nas: it's not about different priorities we just work on 10 projects at same time, I really want to have some more time to may submit all the OSHW projects we have. I will blog about what you did :)
[17:37:36] <Tsvetan> jo0nas the FreedomBox-HSK probably will be also our first RYF certified product
[18:20:49] <jo0nas> cool - all of it: the amount of projects you do, intending to report all OSHW project, blogging about Teres-I u-boot mainling, and RYF certification \0/
[19:56:47] <jo0nas> Tsvetan: I bet it you offer a metal box for the OlinuXino A64 then that will raise sales among people wanting a more powerful/modern box than the Lime2 for FreedomBox
[22:26:17] <Antitrack> freedombox-branded device? which one?
[22:46:18] <xcko> I believe it's the one at the top of the olimex.com page
[22:48:31] <xcko> https://olimex.wordpress.com/2019/04/22/freedombox-your-private-box-of-freedom-for-decentralizing-the-internet-and-keeping-your-privacy-away-from-the-big-brother/
[22:49:00] <Antitrack> ok
