IRC #olimex 2019-05-14[00:00:24] <dddddd> Do you have output in the serial jack?
[00:04:44] <Asara> no sorry
[00:05:02] <Asara> i could test it again and check the serial out, but i didn't at that time
[00:06:39] <dddddd> No worries.
[00:07:49] <dddddd> Here, no output. Another case would be nice. jo0nas, how do you tested it? (to reproduce)
[00:21:37] <dddddd> I'm cross-compiling using aarch64-linux-gnu-* (Debian 7.2.0-11) from i686 VM
[00:27:03] <dddddd> ACTION upgrading, just in case
[00:44:14] <dddddd> same results with Debian 8.3.0-2
[01:17:06] <jo0nas> dddddd: As I wrote earlier, I have mainly tested with Debian u-boot and Debian ATF (mainline, not the outdated Allwinner fork)
[01:17:58] <dddddd> We're talking about mainline (non-debian), as merged
[01:17:59] <jo0nas> I compile on the Teres-I
[01:18:25] <dddddd> At least I'm talking about that (from official repo)
[01:18:25] <jo0nas> I have not tested mainline u-boot yet
[01:18:38] <dddddd> But, there's where it got merged...
[01:19:31] <dddddd> Maybe I'm misunderstanding the Tested-by: line
[01:38:31] <xcko> looks like the debian arm-trusted-firmware package in buster has no patches either (upstream is github.com/ARM-software/arm-trusted-firmware)
[01:44:22] <xcko> looks like this is the patch to uboot that debian has https://sources.debian.org/patches/u-boot/2019.01+dfsg-6/sunxi/teres-i.patch/
[01:45:16] <xcko> maybe this applies too https://sources.debian.org/patches/u-boot/2019.01+dfsg-6/sunxi/sun50i_i2c_init.patch/
[01:47:37] <xcko> list of patches for u-boot in debian buster https://sources.debian.org/patches/u-boot/2019.01+dfsg-5/
[01:51:18] <dddddd> I think we looked at that and it's already merged (and a bit more)
[01:51:51] <dddddd> """yes (and upstream even has one extra line to fix enable USB driver)"""
[01:54:04] <dddddd> I was looking at the mksunxiboot, that debian also seems to use (I'm following the README instead, to write spl/itb to uSD)
[01:54:42] <dddddd> https://sources.debian.org/patches/u-boot/2019.01+dfsg-5/tools-generic-builds.patch/
[02:16:47] <dddddd> I think it doesn't matter, because for sunxi mksunxiboot is built without that patch
[02:19:08] <dddddd> this line is in that Makefile since... the Makefile exists: hostprogs-$(CONFIG_ARCH_SUNXI) += mksunxiboot
[02:37:17] <dddddd> ACTION founds https://packages.debian.org/buster/u-boot-sunxi
[02:51:33] <dddddd> after hacking a bit with the files in that package I can see output on serial (but it doesn't get far, because... hacking; I need to create proper files)
[09:30:14] <leon-anavi> hi
[09:46:20] <jo0nas> good morning
[11:56:02] <deesix> hi
[12:18:29] <jo0nas> dddddd: what I meant to say is that I don't have a timemachine and didn't test _current_ mainline back when it was not yet merged
[12:19:22] <jo0nas> what works for me is this:
[12:20:07] <jo0nas> git checkout f95fdf2
[12:20:18] <jo0nas> git cherry-pick 997b85
[12:20:39] <jo0nas> make teres_i_defconfig
[12:21:04] <jo0nas> BL31=/usr/lib/arm-trusted-firmware/sun50i_a64/bl31.bin make -j5
[12:21:22] <jo0nas> that's it.
[12:21:44] <jo0nas> I can confirm that 2019.07-rc1 does *not* work
[12:22:03] <jo0nas> I am currently trying to narrow down when it started failing
[12:22:28] <jo0nas> ...and f95fdf2 is as far as I got now...
[12:23:56] <jo0nas> This works too: v2019.04-288-g0a5228be8
[12:24:50] <dddddd> jo0nas, of course you didn't tested the merge before the merge :) I'm thinking if my problem is caused by the cross-compilation, so I guess my next step is to native-compile. Good to know that rc1 is not working, thanks.
[12:28:50] <jo0nas> or you could try cross-compile that exact checkout+cherry-pick I point out above
[12:29:11] <jo0nas> ...linked with that same ATF!
[12:30:22] <dddddd> yes, I'm doing that before trying native
[12:49:56] <dddddd> f95fdf2+997b85 works (cross-compiled)
[12:51:21] <jo0nas> good!
[12:52:03] <jo0nas> This should work too: v2019.04-566-gb4fde1633e
[12:52:51] <jo0nas> ...as should this: v2019.04-699-gc2bb9c5b9e
[12:53:32] <dddddd> For reference, ATF is mainline at f2f084659890
[13:06:58] <dddddd> c2bb9c5b9e is pretty close to 2019.07-rc1
[13:06:59] <jo0nas> This is missing: CONFIG_SPL_TEXT_BASE=0x10060
[13:07:21] <jo0nas> ...since the commit right before -rc1
[13:08:25] <dddddd> that's closer xD
[13:09:17] <jo0nas> u-boot 2019.07-rc1 works with teres-1 when this one line is added to defconfig: CONFIG_SPL_TEXT_BASE=0x10060
[13:11:25] <dddddd> I'm trying that after the merge commit
[13:14:05] <jo0nas> ACTION trying HEAD now
[13:15:05] <jo0nas> works!
[13:23:39] <dddddd> After the merge, it also works. I'm getting """EHCI timed out on TD - token=0x80008c80""" sometimes, I guess it depends on timming (I'm stopping the u-boot countdown via serial to get to its prompt and do the load mmc, setenv & booti dance)
[13:24:24] <dddddd> good catch, anyway, jo0nas! Bad luck with that config change.
[13:33:23] <jo0nas> I guess those timeouts are due to the known broken support for builtin keyboard
[13:34:08] <dddddd> So, it was in include/configs/sunxi-common.h before (which has some #if we might need to study, to cover all cases; maybe?)
[13:37:33] <dddddd> It's based on CONFIG_SUNXI_SRAM_ADDRESS
[13:43:53] <dddddd> default 0x10000 if MACH_SUN9I || MACH_SUN50I || MACH_SUN50I_H5
[13:44:00] <dddddd> It's fine
[13:44:09] <jo0nas> not sure what you are talking about now
[13:44:36] <jo0nas> EHCI timeouts? SPL_TEXT_BASE?
[13:45:06] <dddddd> Oh, sorry... SPL_TEXT_BASE
[13:45:19] <jo0nas> ACTION posted a bugfix patch to mainline u-boot mailinglist about SPL_TEXT_BASE
[13:47:44] <dddddd> Looking at the commit that moved it to the defconfig, I see the #if in the previous implementation. I was wondering about the #if, but It's clear now that for teres/sun50i SUNXI_SRAM_ADDRESS is always 0x10000, so 0x10060 is perfect for us.
[13:48:26] <dddddd> Thank you very much!
[13:49:16] <jo0nas> waiting for mailinglist moderator approval - for some reason it flags my patches as non-member posts
[13:57:58] <dddddd> Maybe you can ask about that at #u-boot
[13:58:22] <jo0nas> already did :-)
[13:59:02] <dddddd> I see the question in #linux-sunxi
[14:00:42] <jo0nas> ahh
[14:00:58] <jo0nas> probably makes sense to join #u-boot ;-)
[15:12:47] <dddddd> Tsvetan, if I order a new LCD for TERES-I, will I get --for sure-- one which doesn't make this awful noise?
[16:11:25] <Tsvetan> dddddd the noise do not come from the LCD!
[16:11:37] <Tsvetan> it's the DCDC and inductor which make the noise
[16:12:11] <dddddd> Tsvetan, I heard about changing LCD and noise disappearing.
[16:12:15] <Tsvetan> please take picture of your main board and send to firstname.lastname@example.org so we can see what inductor, capacitors etc are on board
[16:12:26] <Tsvetan> I doubt
[16:12:36] <Tsvetan> the noise comes from the inductor
[16:13:58] <dddddd> xcko ^
[16:14:37] <dddddd> Tsvetan, I will; thanks
[23:20:00] <xcko> dddddd: This thread helped me a lot https://www.olimex.com/forum/index.php?PHPSESSID=f6e4pbl8dbv86tdn3mhfkugd14&topic=5969.0
[23:21:12] <dddddd> I read that thread a while ago. IIRC it's about the board modifications...
[23:21:25] <xcko> the source of the noise is the main board, but it only occurs with some screens. I have two main boards and two lcd's, one lcd creates very loud noise with either board, the other is silent with both boards
[23:22:02] <xcko> it details how khumaran had two lcds for one board and only had noise problems with a particular screen
[23:23:16] <dddddd> Which is the LCD that doesn't makes noise? Does olimex sell it?
[23:23:58] <dddddd> I misunderstood you some days ago, about changing LCD (I understand it's the same model)
[23:26:44] <dddddd> Do you know what's the spec of the quiet LCD that makes it so?
[23:27:03] <dddddd> *quiet board/LCD combo
[23:29:27] <xcko> I bought two lcd's from olimex, exact same model, for the teres laptop. I have no idea why one is quiet and one is not.
[23:32:36] <xcko> https://olimex.wordpress.com/2017/11/03/teres-i-update-first-feedback-from-our-customers/
[23:33:16] <xcko> I tried this fixes but it was way too loud and not effective enough.
[23:35:52] <dddddd> So, I understood correctly. I just re-read the thread and my fears are the same. I can hack the hardware and don't fix the problem. I really want to avoid that. Blindly buying a new LCD is like a lottery.
[23:37:30] <xcko> dddddd: yup. I wish I could give you better answers.
[23:37:34] <dddddd> Tsvetan, LCD seems to matter a lot, and adding components might not fix it, it seems (as per the thread and other people experience). What's the _proper_ fix?
[23:37:53] <dddddd> No worries xcko. That's really helpful, thanks!