IRC #olimex 2019-05-10

[00:35:56] <dddddd> first attempt to use (just) new u-boot/ATF: no screen. Let me attach the serial...
[00:51:00] <xcko> dddddd: for the noise, I ended up buying a new display and that fixed it. I tried the tricks of adding some padding to deaden the mainboard but it was really loud
[00:51:36] <xcko> khumaran had a thread on the olimex forums that described my issue
[00:52:46] <xcko> so you're using a patched atf? do you know where that patch is or if it's been submitted upstream?
[00:53:26] <xcko> and yeah, if you wanna post your lsmod and dmesg output for your working setup I'll take a peak
[00:53:54] <dddddd> oh, so sad! Then, if a new display fixed it, it's not a [enterely] board problem. Did you asked olimex for a replacement before buying a new one, xcko?
[00:54:13] <dddddd> The patch is in the links posted a bit earlier, xcko
[00:55:17] <dddddd> No output in serial with new new u-boot, but there're some things I can double check yet.
[00:58:23] <xcko> I did not ask for a replacement as I wasn't sure if it would fix it. If Tsvetan wants to reimburse me that's cool, but I figured it comes with the turf of getting an experimental / dev setup
[00:59:37] <xcko> okay I'll check the links. yeah I got a second mainboard too to test as well, and determined that it was related to the display itself
[01:02:26] <dddddd> Thanks for the info!
[01:04:33] <dddddd> Tsvetan, if a (free) replacement is possible, let me know ;) It failed since day 1.
[01:29:32] <xcko> what's the difference between aprtizels atf and ARM upstream?
[01:34:16] <dddddd> Not sure now, but back then it has some patches for pine that were relevant.
[01:35:50] <dddddd> Today I'm using upstream, but can't get it to work (yet?)
[01:36:35] <Asara> ACTION will idle here as well
[01:36:35] <Asara> :)
[01:38:46] <dddddd> Hi! (:
[01:39:07] <dddddd> I think I know what I'm doing wrong, let's see...
[01:40:32] <xcko> it seems debians atf-allwinner package uses apritzels repo as upstream. if you get something working with arm's upstream, I'd like to give it a test :)
[01:44:50] <dddddd> hmm, it wasn't it; I'm using the master branch (it used to be an allwinner in the docs)
[01:46:24] <jo0nas> debian has _both_ a forked ATF and mainline ATF pakcaged!
[01:47:48] <jo0nas> arm-trusted-firmware is mainline ATF, atf-allwinner is older fork now discouraged!
[01:50:04] <jo0nas> the various variants of u-boot patches are listed at https://wiki.debian.org/InstallingDebianOn/Olimex/Teres-I?action=recall&rev=56#u-boot
[01:51:10] <jo0nas> sounds like the variant dddddd is using is what I call "anarsoul+Icenowy" in above link
[01:51:29] <jo0nas> that's the variant Harald promoted
[01:52:06] <dddddd> That's what I usually use, yes. Today I'm trying mainline ATF
[01:55:40] <jo0nas> looking forward to read about your tests, dddddd - heading to bed now. Good night!
[01:56:29] <dddddd> see you!
[02:27:02] <dddddd> """If you run into size issues with the resulting U-Boot image file [...]""" How much is too much? I can see that u-boot-sunxi-with-spl.bin is about 100K bigger this time.
[02:56:52] <xcko> hmm did you build with debugging symbols?
[03:24:19] <dddddd> I tried DEBUG=0 too, while building ATF (but it's a small file anyway, by itself). For u-boot I don't set anything about debug symbols.
[04:54:43] <xcko> hm well is 100k too much? did you test it?
[05:48:23] <xcko> also seems like suspending in 5.1.0 on the teres does not turn off the display, not too surprising
[07:33:17] <xcko> hibernate works perfectly though, so that's cool
[07:50:53] <Asara> hm... tried to compile u-boot from master for the teres-1 and am not getting the backlight turned on
[07:56:44] <xcko> Asara: interesting, which source did you use for the arm-trusted-firmware?
[08:01:28] <Asara> https://github.com/ARM-software/arm-trusted-firmware.git
[08:12:24] <xcko> I think deesix had the same experience. I'm using the debian provided uboot / atf stuff,
[08:12:59] <xcko> I would check https://wiki.debian.org/InstallingDebianOn/Olimex/Teres-I?action=recall&rev=56#u-boot and check the debian sources for arm-trusted-firmware right above that section or use the binaries right below it
[08:15:09] <xcko> I've had success booting with the binaries from box.redpill.dk (that jo0nas manages). If you wanted to dig into why it's not working, I'd check debians atf sources and see if they differ from arm's. Maybe there was a recent regression or something in the arm repo
[08:17:48] <xcko> what I did was boot into the debian image provided by redbox.dk and used u-boot-install-sunxi64
[08:21:20] <Asara> hm... alright thanks for the tip
[08:21:34] <Asara> im going to head to bed now... well past my bedtime and I have work in the morning. thanks xcko, and night!
[08:22:21] <xcko> np Asara night!
[10:26:17] <dddddd> xcko, not 100K, but 100K bigger (> 600K total). Sure I tested.
[10:31:35] <dddddd> no serial output at all
[10:38:40] <dddddd> I'll try more ATF/u-boot combinations later today
[10:41:16] <leon-anavi> morning
[10:41:29] <dddddd> hi
[10:50:14] <jo0nas> morning
[11:06:41] <jo0nas> dddddd: I am eager to hear about your tests!
[11:08:38] <jo0nas> ACTION tested just now with the binary u-boot files built by Harald (linked from bottom of "anarsoul+Icenowy" at https://wiki.debian.org/InstallingDebianOn/Olimex/Teres-I?action=recall&rev=56#u-boot ) with up-to-date Debian 4.19 kernel, but that doesn't provide content in the backlight or power_supply sys dirs
[11:10:29] <jo0nas> ACTION suspects that whatever dddddd experienced in the past was done with derived linux kernel, not (only) close-to-mainline sunxi fork of u-boot
[11:20:12] <diego71> jo0nas: power supply is missing in mainline kernel for 4.19. There are some proposed patch around, but I don't know if they arrive in mainline at the end...
[11:20:35] <diego71> (ie: support for axp803 in teres)
[11:25:49] <dddddd> jo0nas, yesterday I tested mainline ATF with mainline u-boot.
[11:29:12] <dddddd> jo0nas, is /sys/devices/platfrom/backlight/backlight/backlight/brightness also unavailable?
[11:40:05] <jo0nas> there is not even a /sys/devices/platform/backlight - I'll go load a bunch of modules to see if that helps...
[11:40:32] <jo0nas> ...and try with linux 5.0.2 - thanks, diego71
[11:41:53] <jo0nas> diego71: any pointers to those patches would be helpful!
[11:49:00] <dddddd> Harald documented our changes quite well.
[11:49:24] <dddddd> See the links to bug reports and so, in the forum.
[11:49:31] <dddddd> ACTION BBL
[12:48:05] <diego71> jo0nas: there is this, but needs some love: https://patchwork.kernel.org/patch/10626557/
[12:50:10] <diego71> there some older : https://patchwork.ozlabs.org/cover/816303/
[13:13:51] <jo0nas> thanks, diego71!
[13:16:46] <jo0nas> This seems related and apparently got somewhat adopted: https://patchwork.kernel.org/cover/10902029/
[13:28:04] <diego71> good, adding dts bits needed for other platform should be easy
[13:41:43] <jo0nas> the builtin keyboard in Teres-I currently (with mainline u-boot, I mean) fails to load, whereas externally plugged in USB1.1 keyboard is detected. Could it be that the equivalent of https://patchwork.kernel.org/patch/10902037/ is needed for u-boot as well?
[13:43:01] <jo0nas> ...the equivalent of the DEBOUNCE_TIME in that patch, I mean
[16:33:54] <dddddd> Doesn't the keyboard/pad need some kind of firmware?
[16:37:51] <dddddd> SOFTWARE/A64-TERES/TERES-KBD-RELEASE/README.md
[16:39:05] <dddddd> in https://github.com/OLIMEX/DIY-LAPTOP (cloned a while ago, not sure if it's on the same path yet)
[16:52:18] <dddddd> In the mainline u-boot dts, this is an old and confusing typo """The A64 chip cannot work without this regulator off, although"""
[16:55:44] <diego71> dddddd: the firmware is already loaded in the hardware
[16:56:05] <diego71> for the keyboard
[16:56:59] <dddddd> oh, not during boot. Thanks, diego71
[17:29:31] <dddddd> Do you know a quick way (other than saving the HTML pages one by one) to export personal messages from the forum? I'd like to keep local copies of them, for reference (conversations with Harald).
[17:35:44] <diego71> wget can download recursively pages from sites, but if they are just few pages, it's faster save them from browser
[17:37:46] <dddddd> yes, I was looking for something provided by the forum itself. Managing the cookie for wget is possible but not funny.
[17:43:03] <dddddd> About early keyboard support: """The thing you have to power up [for] the usb host is GPIO L7"""
[18:17:03] <dddddd> xcko, another kernel I used: 4.16.0-rc3 (the lastest version available in that moment)
[19:01:40] <dddddd> OK! Finally found the info about the backlight, jo0nas. Relevant modules are pwm_sun4i and pwm_bl.
[19:02:33] <dddddd> ... or should I say were (March, 2018)
[20:22:29] <jo0nas> dddddd: thanks! Do you also have a URL?
[20:22:59] <jo0nas> ...even if not, module names are quite helpful - much appreciated!
[20:23:23] <dddddd> Is in personal messages in the forum, not public, jo0nas.
[20:23:36] <dddddd> hope it helps!
[20:23:38] <xcko> dddddd: if you could post your dmesg output, I'd like to take a look and compare what gets loaded / detected
[20:36:03] <dddddd> I have a bunch of logs from back when we're experimenting, but I guess they're not relevant anymore. I can get one, later from the image of lambda, if you don't get it before. Is that what you're asking for, xcko?
[20:45:41] <xcko> yeah, the one that has backlight working - if it's not too much of a hassle :)
[21:35:06] <dddddd> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=892786 via https://www.olimex.com/forum/index.php?topic=6092.0 names the modules, jo0nas
[23:30:29] <Antitrack> jo0nas: I wont call myself "Antitrack" on a job interview yaknow? :D