**** BEGIN LOGGING AT Wed Jun 13 03:00:02 2018 Jun 13 07:31:12 Anyone know what/who updates the hwclock/rtc on the "FSLC Framebuffer" distro? I see I have an /etc/timestamp in my rootfs, but nobody seems to use it. Does the kernel update the rtc from the system clock? Jun 13 07:39:24 tasslehoff: there was an init script that did that, but if they've got systemd then it isn't used Jun 13 07:39:38 systemd iirc uses the build time of systemd as a fallback Jun 13 07:42:27 rburton: yeah, I used that script on angstrom before. seems to me that if I change the systemclock now, I have to make sure to update the rtc myself (with hwclock) Jun 13 07:42:50 yeah thats not right Jun 13 07:46:08 rburton: I masked/stopped systemd-timesyncd, called date -s to change system time, and then called shutdown. turning on again, the rtc does not reflect what I set with date -s Jun 13 07:47:48 surely timesync is the thing that would be changing the rtc? Jun 13 07:49:02 rburton: I'll check that. I thought that was just ntp-stuff for systemd Jun 13 07:50:32 ooh, timedatectl :D Jun 13 07:52:40 never used that one, but it will be useful debugging. Jun 13 10:06:48 khem, so I counter-tested: same image is ok on qemuarm but shows alignment faults on real hw Jun 13 10:06:54 heh Jun 13 10:07:25 (last time was worse..kernel was not even decompressing with gcc7) Jun 13 10:08:24 khem, so I guess armv5t is flawed in oe-core master Jun 13 10:08:30 rburton, ^ Jun 13 10:23:07 giving now a try with gcc8.1 Jun 13 14:19:26 khem, fyi kernel and images built with gcc8.1 run fine under qemu Jun 13 14:19:34 (pxa) Jun 13 14:19:46 I'll test on Zaurus later on Jun 13 14:27:28 gcc 8 can't build the upstream stable kernel?! #include not found? Jun 13 14:28:13 I have built now a korg 4.14 with it Jun 13 15:15:49 ant_work: ok but it fails on real box ? Jun 13 15:16:04 I'll tell you in a few hours, device is at home Jun 13 15:16:46 ant_work: ok, keep in mind that anything below armv5te is going to be a bit problematic since upstream sort of deprecated them Jun 13 15:16:59 tlwoerner: which stable ? Jun 13 15:17:23 khem, btw kernel 4.4 fails to build Jun 13 15:17:42 khem: 4.16 (.15) Jun 13 15:18:10 ant_work: yes, I expect that, there are patches for backporting available Jun 13 15:18:14 khem: i'll check with meta-meson, i know they're using 4.16 as well, although i think they just switched to 4.17.1 Jun 13 15:18:35 tlwoerner: if you point me to errors I might be able to help Jun 13 15:18:48 several fixes have been done in mainline Jun 13 15:19:14 khem, it is 4.4.136 (LTS) so should have the backports Jun 13 15:19:20 khem: okay, let me do a little more research and get back, i was just looking for a quick, "oh yea, look here" Jun 13 15:19:55 I'll check this, 4.14.48 has the backports and builds fine Jun 13 15:20:25 khem, 4.4 is for armv4...do we still have future? Jun 13 15:30:19 ant_work: I think bleak one Jun 13 15:30:38 you might have to end with gcc8 Jun 13 15:30:44 gcc9 will drop it Jun 13 15:32:41 I got it building on 3.16.7 but had to backport quite a bit of fixes (and I haven't tried to boot it yet) Jun 13 15:39:56 khem, about alignment trap, it seems to me it is just one instruction Jun 13 15:40:04 https://pastebin.com/FRQpXibj Jun 13 15:40:55 if 8.1 is ok good, otherwise I'll try to debug with gdb Jun 13 15:42:14 should be the instruction 0xe1cc00d0 Jun 13 15:49:15 ant_work: yes PC=0xb6f28250 can you dump smap and see which .so is mapped there Jun 13 15:50:27 ant_work: cat /proc/431/smaps Jun 13 15:50:56 might give the mem map where we can locate where this intruction is coming from. It might be libc Jun 13 15:53:22 ant_work: the instr is ldrd r0, [ip, #8] Jun 13 15:53:25 ARMv5 ARM: "If the load address is not doubleword-aligned, the results are UNPREDICTABLE." Jun 13 15:54:06 so armv5 does not support word-aligned LDRD. Jun 13 15:54:12 like armv6+ Jun 13 15:55:47 ok, I doubt it is libc because I got this with both glibc and musl Jun 13 16:00:16 OK but its some common function Jun 13 16:00:32 if you print smap then we will know which library its coming from Jun 13 16:00:59 I need the real hw, I'll do that later on Jun 13 16:01:00 we need 8byte alignment for ldrd to work on armv5 and it seems to be using 4byte Jun 13 16:01:33 reasons could be wrong type or we might need to insert correct alignment Jun 13 16:03:08 qemu does correct this Jun 13 16:03:18 ..sadly... Jun 13 16:04:43 khem, anyway, I am sure gcc7.2 was ok because last year we got ldrd/strd issue with first gcc 7 Jun 13 16:04:54 and you fixed it in 7.2 Jun 13 16:04:59 maybe it is really 7.3 Jun 13 16:05:14 then it should work with 8.1 as well Jun 13 22:38:25 khem, bad news wrt alignment traps vs gcc8.1 Jun 13 22:39:31 much more than with gcc7.3 Jun 13 22:40:45 https://pastebin.com/2X0Sjt9n Jun 13 22:45:52 khem, the smaps https://pastebin.com/ABrJie74 Jun 13 22:50:04 hm, seems /usr/lib/libc.so Jun 13 22:51:34 (musl this build) Jun 13 23:01:13 khem, we have one bug in libc apparently ... and surely there is a qemu bug as well :] Jun 13 23:34:23 ant_home: ok Jun 13 23:35:38 ant_home: it seems its code generated by compiler so in the end it could be related Jun 13 23:36:16 ant_home: can you run arm-objdump -d -S libc.so inside musl build dir ? Jun 13 23:38:03 yes, I am compiling binutils Jun 13 23:43:20 ant_home: What is compiler cmdline Jun 13 23:43:29 especially -march/-mcpu/-mtune Jun 13 23:44:03 https://pastebin.com/XHvcJCkN Jun 13 23:50:53 khem, od https://pastebin.com/DcDJGD9V Jun 13 23:54:28 sorry, this is the tail Jun 13 23:55:46 is big, let me see where to upload it.. Jun 13 23:57:23 4064c: e1cc00d0 ldrd r0, [ip] Jun 13 23:59:22 khem, https://filebin.net/awzmx3eeraa91izk Jun 14 00:09:59 afais 0xe1cc00d0 -> __setrlimit or 0xe1cc00d8 -> readdir Jun 14 00:10:25 the latter Jun 14 00:11:24 readdir could explain the alignment traps in the log Jun 14 00:12:14 ..but the alignment is 8 afais.. Jun 14 00:12:16 1d040: e1cc00d8 ldrd r0, [ip, #8] Jun 14 00:12:40 sigh 2 o' clock here... Jun 14 00:12:43 have to go Jun 14 00:13:15 gn Jun 14 01:45:45 khem: here's the error: https://pastebin.com/j5Eaazky Jun 14 01:46:02 as you can see, the build of the kernel itself completes fine Jun 14 01:46:28 it's the compile of the dt tools that fails Jun 14 01:46:49 linux-stable-4.17.1 compiles just fine, so i'll just update to 4.17.1 and consider it done :-) Jun 14 01:53:17 tlwoerner: I think gcc is not finding standard compiler headers Jun 14 01:56:57 khem: which is weird (?), it's obviously finding it for everything else Jun 14 01:57:16 i.e. other non-kernel C programs **** ENDING LOGGING AT Thu Jun 14 03:00:04 2018