≡
[16:08:16] <jo0nas> hi
[18:01:42] <valhalla> hello from a certain overflowing room at fosdem
[18:02:51] <dddddd> Hello, valhalla. What's the topic now?
[18:03:01] <valhalla> olimex :)
[18:03:48] <valhalla> (the teres talk)
[18:06:19] <dddddd> https://stream.fosdem.org/k4201.m3u8
[18:06:38] <valhalla> btw, it is streamed somewhere on the... there :)
[18:11:28] <dddddd> ACTION experience the LCD high pitch bug
[18:12:02] <valhalla> ACTION had the touchpad issues instead
[18:12:15] <dddddd> nice to hear expected mainline kernel support!
[18:12:19] <valhalla> (and that made it unusable for fosdem :( )
[18:12:36] <valhalla> indeed! (mainline)
[18:30:57] <dddddd> valhalla, remember them to send a TERES to that sunxi developer they promised to (:
[18:31:28] <dddddd> icenowy IIRC
[18:32:46] <dddddd> I hacked a bit with AFT/u-boot, but I'm surely lacking skills for many things
[18:33:33] <valhalla> done
[18:34:12] <dddddd> but seeing (mainline) u-boot text on LCD was great for a beginner like me (o powered up the LCD myself!)
[18:34:27] <dddddd> great, thanks!
[18:35:27] <diego71> dddddd: it will be nice, if you document what have you done, so somone else can improve what you alredy done
[18:38:01] <dddddd> diego71, It's just poking a couple of registers, following instructions on the schematics pdf and a couple of datasheets. But, sure...
[18:44:14] <dddddd> diego71, I don't have the code right here now (not far, maybe later)... but I use this repo/patch as inspiration https://github.com/apritzel/arm-trusted-firmware/commit/ae78724247a01560164d607ed66db111c74d8df0
[18:44:59] <dddddd> pins and voltages are different and on GPIO is involved, but that's the idea
[18:45:09] <dddddd> *one GPIO
[18:45:56] <diego71> yes, but if you write down somewhere, ppl don't have to try out how to do again
[18:46:44] <diego71> maybe you can fork apritzel git repository, and publish your changes, for examples
[18:50:58] <dddddd> with AFT compiled, it's just http://git.denx.de/?p=u-boot.git;a=blob;f=board/sunxi/README.sunxi64;hb=HEAD
[19:01:25] <dddddd> I guess people who knows this stuff can code it in five minutes, much better than my hackish patch. And it seems Olimex is working on it too... Don't know if the patch is worth publishing, but I'll do it anyway a bit later.
[19:03:55] <dddddd> On thing I don't know how to do is the sleep/wait documented, so I just printed some debug msg hoping that consumed enough time.
[19:04:49] <dddddd> s/On/One/
[19:17:21] <dddddd> s/AFT/ATF/ (I do that typo a lot, sorry)
[19:36:35] <jo0nas> don't expect Olimex people to do much coding - their skills are in producing the hardware
[19:36:48] <jo0nas> dddddd: ^
[19:40:47] <dddddd> jo0nas, maybe not them directly, but one slide at FOSDEM shows that armbian with mainline support is a to be expected, to replace the Ubuntu image.
[19:40:58] <dddddd> s/is a/is/
[19:42:05] <jo0nas> if I understand you correctly (I didn't watch the talk), Olimex will shift from relying on Ubuntu to relying on Armbian - that does not change my point that Olimex cannot be expected to fix code
[19:42:27] <jo0nas> I too recommend that you document and publish whatever hacks you throw together
[19:43:06] <jo0nas> others may later do better - maybe independent from your dirty hacks but maybe *helped* by them!
[19:44:18] <dddddd> diego71, http://213.32.20.167:8000/tmp-teres_lcd-powerup_hack_in_atf.txt
[19:45:08] <jo0nas> both Ubuntu and Armbian are mainly distributions - which means they *might* push their patches upstream but possibly not all end upstream, one reason is that they - like you - feel that their patches are too tied to their own environment to be really useful for general consumption
[19:45:31] <dddddd> to be patched on top of apritzel cbb89f326fab8635c5cc39fd540792f0d2fda20e
[19:50:09] <dddddd> Something comes from another repo, with a couple of patches (for the minimal dts)... let me write it down...
[19:54:47] <dddddd> cherry pick [0] on top of [1]
[19:55:10] <dddddd> [0] https://github.com/Icenowy/u-boot/commit/960ae79950a2b0a8d2e62bb3dfb5727764512a8b
[19:57:31] <dddddd> [1] https://github.com/anarsoul/u-boot-pine64/commit/c386be61da97beffb4613a05f6b3a8fd1a099fa9
[19:58:03] <dddddd> I guess you can see that this is a bit hack! :D
[20:00:43] <dddddd> And those repos are pine related and fast-moving/WIP. Use everything at your own risk (specially my patch --which you can consider public domain from my part)
[20:03:02] <dddddd> I used the AXP803 datasheet to find the registers.
[20:05:29] <dddddd> And the Olimex schematics for the procedure and to determine the GPIO of the A64
[20:05:57] <dddddd> Also, the A64 user manual, about the GPIO too.
[20:06:19] <dddddd> Hope I didn't miss anything in this crude description.
[20:16:16] <jo0nas> thanks, dddddd - would be nice if you put these comments here into the header of that patch file
[20:44:09] <dddddd> jo0nas, updated
[20:44:38] <jo0nas> excellent
[20:45:58] <jo0nas> what I meant was simpler, however: You could add a comment at the top of the patch file itself - just mentioning for future sake, this is nice too!
[20:46:50] <dddddd> I wasn't sure if a comment before the diff may broke the format, so I added it as code-comment.
[20:47:39] <dddddd> Also, I think tabs-vs-spaces are not handled correctly during copy/paste. ATF uses tabs, IIRC
[20:49:30] <jo0nas> Here is an example of a diff with comments on top - with a link to the spec of that format: https://anonscm.debian.org/git/collab-maint/radicale.git/tree/debian/patches/2001_debianize_config.patch
[20:51:17] <dddddd> nice to know, thanks
[20:51:54] <jo0nas> here is a slightly more complex comment (with indented lines): https://anonscm.debian.org/git/pkg-bitcoin/bitcoin.git/tree/debian/patches/1001_use_system_leveldb.patch
[20:52:22] <dddddd> Is that spec debian specific?
[20:52:27] <jo0nas> I don't know the limits of what can be put in comments, but we use that format extensively in Debian
[20:52:55] <jo0nas> DEP3 is a Debian invention, yes - but should be usable more broadly
[20:53:10] <dddddd> ok
IRC #olimex 2018-02-03
[15:59:16] <dddddd> hi[16:08:16] <jo0nas> hi
[18:01:42] <valhalla> hello from a certain overflowing room at fosdem
[18:02:51] <dddddd> Hello, valhalla. What's the topic now?
[18:03:01] <valhalla> olimex :)
[18:03:48] <valhalla> (the teres talk)
[18:06:19] <dddddd> https://stream.fosdem.org/k4201.m3u8
[18:06:38] <valhalla> btw, it is streamed somewhere on the... there :)
[18:11:28] <dddddd> ACTION experience the LCD high pitch bug
[18:12:02] <valhalla> ACTION had the touchpad issues instead
[18:12:15] <dddddd> nice to hear expected mainline kernel support!
[18:12:19] <valhalla> (and that made it unusable for fosdem :( )
[18:12:36] <valhalla> indeed! (mainline)
[18:30:57] <dddddd> valhalla, remember them to send a TERES to that sunxi developer they promised to (:
[18:31:28] <dddddd> icenowy IIRC
[18:32:46] <dddddd> I hacked a bit with AFT/u-boot, but I'm surely lacking skills for many things
[18:33:33] <valhalla> done
[18:34:12] <dddddd> but seeing (mainline) u-boot text on LCD was great for a beginner like me (o powered up the LCD myself!)
[18:34:27] <dddddd> great, thanks!
[18:35:27] <diego71> dddddd: it will be nice, if you document what have you done, so somone else can improve what you alredy done
[18:38:01] <dddddd> diego71, It's just poking a couple of registers, following instructions on the schematics pdf and a couple of datasheets. But, sure...
[18:44:14] <dddddd> diego71, I don't have the code right here now (not far, maybe later)... but I use this repo/patch as inspiration https://github.com/apritzel/arm-trusted-firmware/commit/ae78724247a01560164d607ed66db111c74d8df0
[18:44:59] <dddddd> pins and voltages are different and on GPIO is involved, but that's the idea
[18:45:09] <dddddd> *one GPIO
[18:45:56] <diego71> yes, but if you write down somewhere, ppl don't have to try out how to do again
[18:46:44] <diego71> maybe you can fork apritzel git repository, and publish your changes, for examples
[18:50:58] <dddddd> with AFT compiled, it's just http://git.denx.de/?p=u-boot.git;a=blob;f=board/sunxi/README.sunxi64;hb=HEAD
[19:01:25] <dddddd> I guess people who knows this stuff can code it in five minutes, much better than my hackish patch. And it seems Olimex is working on it too... Don't know if the patch is worth publishing, but I'll do it anyway a bit later.
[19:03:55] <dddddd> On thing I don't know how to do is the sleep/wait documented, so I just printed some debug msg hoping that consumed enough time.
[19:04:49] <dddddd> s/On/One/
[19:17:21] <dddddd> s/AFT/ATF/ (I do that typo a lot, sorry)
[19:36:35] <jo0nas> don't expect Olimex people to do much coding - their skills are in producing the hardware
[19:36:48] <jo0nas> dddddd: ^
[19:40:47] <dddddd> jo0nas, maybe not them directly, but one slide at FOSDEM shows that armbian with mainline support is a to be expected, to replace the Ubuntu image.
[19:40:58] <dddddd> s/is a/is/
[19:42:05] <jo0nas> if I understand you correctly (I didn't watch the talk), Olimex will shift from relying on Ubuntu to relying on Armbian - that does not change my point that Olimex cannot be expected to fix code
[19:42:27] <jo0nas> I too recommend that you document and publish whatever hacks you throw together
[19:43:06] <jo0nas> others may later do better - maybe independent from your dirty hacks but maybe *helped* by them!
[19:44:18] <dddddd> diego71, http://213.32.20.167:8000/tmp-teres_lcd-powerup_hack_in_atf.txt
[19:45:08] <jo0nas> both Ubuntu and Armbian are mainly distributions - which means they *might* push their patches upstream but possibly not all end upstream, one reason is that they - like you - feel that their patches are too tied to their own environment to be really useful for general consumption
[19:45:31] <dddddd> to be patched on top of apritzel cbb89f326fab8635c5cc39fd540792f0d2fda20e
[19:50:09] <dddddd> Something comes from another repo, with a couple of patches (for the minimal dts)... let me write it down...
[19:54:47] <dddddd> cherry pick [0] on top of [1]
[19:55:10] <dddddd> [0] https://github.com/Icenowy/u-boot/commit/960ae79950a2b0a8d2e62bb3dfb5727764512a8b
[19:57:31] <dddddd> [1] https://github.com/anarsoul/u-boot-pine64/commit/c386be61da97beffb4613a05f6b3a8fd1a099fa9
[19:58:03] <dddddd> I guess you can see that this is a bit hack! :D
[20:00:43] <dddddd> And those repos are pine related and fast-moving/WIP. Use everything at your own risk (specially my patch --which you can consider public domain from my part)
[20:03:02] <dddddd> I used the AXP803 datasheet to find the registers.
[20:05:29] <dddddd> And the Olimex schematics for the procedure and to determine the GPIO of the A64
[20:05:57] <dddddd> Also, the A64 user manual, about the GPIO too.
[20:06:19] <dddddd> Hope I didn't miss anything in this crude description.
[20:16:16] <jo0nas> thanks, dddddd - would be nice if you put these comments here into the header of that patch file
[20:44:09] <dddddd> jo0nas, updated
[20:44:38] <jo0nas> excellent
[20:45:58] <jo0nas> what I meant was simpler, however: You could add a comment at the top of the patch file itself - just mentioning for future sake, this is nice too!
[20:46:50] <dddddd> I wasn't sure if a comment before the diff may broke the format, so I added it as code-comment.
[20:47:39] <dddddd> Also, I think tabs-vs-spaces are not handled correctly during copy/paste. ATF uses tabs, IIRC
[20:49:30] <jo0nas> Here is an example of a diff with comments on top - with a link to the spec of that format: https://anonscm.debian.org/git/collab-maint/radicale.git/tree/debian/patches/2001_debianize_config.patch
[20:51:17] <dddddd> nice to know, thanks
[20:51:54] <jo0nas> here is a slightly more complex comment (with indented lines): https://anonscm.debian.org/git/pkg-bitcoin/bitcoin.git/tree/debian/patches/1001_use_system_leveldb.patch
[20:52:22] <dddddd> Is that spec debian specific?
[20:52:27] <jo0nas> I don't know the limits of what can be put in comments, but we use that format extensively in Debian
[20:52:55] <jo0nas> DEP3 is a Debian invention, yes - but should be usable more broadly
[20:53:10] <dddddd> ok
