| 01:34.55 | *** join/#qi-hardware fengling (~fengling@2002:6fc6:1d36:0:b13d:5e5c:4fa4:57e8) |
| 01:52.24 | *** join/#qi-hardware Atomic_9eHcd (~atomic@66-215-119-163.dhcp.atsc.ca.charter.com) |
| 02:07.36 | *** join/#qi-hardware atommann (~atommann@58.251.2.94) |
| 02:31.01 | *** join/#qi-hardware wpwrak (~werner@154-164-231-201.fibertel.com.ar) |
| 02:31.28 | *** join/#qi-hardware xiangfu (~xiangfu@111.198.29.53) |
| 04:13.23 | *** join/#qi-hardware sb0 (~lekernel@123202036015.ctinets.com) |
| 04:46.29 | *** join/#qi-hardware atommann (~atommann@58.251.2.94) |
| 05:56.19 | *** join/#qi-hardware porchao (~quassel@218.231.187.25.eo.eaccess.ne.jp) |
| 06:57.29 | *** join/#qi-hardware jekhor (~jek@nat-minsk-pool-46-53-200-107.telecom.by) |
| 07:05.51 | eintopf | 0xffffffff80010000 to 0xffffffff (seems like a strtoul instead strtoull) or something like that :) |
| 07:31.29 | *** join/#qi-hardware jekhor_ (~jek@nat3-minsk-pool-46-53-180-107.telecom.by) |
| 07:38.08 | larsc | http://git.denx.de/?p=u-boot.git;a=blob;f=tools/mkimage.c#l87 |
| 07:49.20 | *** join/#qi-hardware sb0 (~sb0@123202036015.ctinets.com) |
| 07:51.37 | *** join/#qi-hardware jekhor__ (~jek@nat-minsk-pool-46-53-200-107.telecom.by) |
| 07:56.20 | *** join/#qi-hardware wolfspraul (~wolfsprau@xd9ba245f.dyn.telefonica.de) |
| 08:01.05 | *** join/#qi-hardware pcercuei (~paul@137.71.226.54) |
| 08:36.30 | eintopf | grml, barebox has the 1:1 tool from u-boot |
| 08:36.51 | eintopf | so if somebody want to fix that, please cc barebox@lists.infradead.org |
| 08:38.25 | eintopf | http://git.pengutronix.de/?p=barebox.git;a=blob;f=scripts/mkimage.c#l346 - yea, patch would not apply but the maintainer will deal with that |
| 08:41.01 | eintopf | also check if params.addr is really a 64 bit type |
| 08:41.08 | eintopf | :| |
| 08:43.06 | eintopf | and if this is not a 64 bit type then I think they need a new format for uImage |
| 08:43.26 | eintopf | that's maybe the reason why they don't support 64 bit addresses yet |
| 08:44.05 | eintopf | if this is true, it's terrible to fix it |
| 08:44.27 | larsc | or fix the kernel to not add the extra 0xff... since this is a 32-bit processor anyway |
| 08:44.48 | eintopf | yep |
| 08:46.45 | larsc | 'load-$(CONFIG_MACH_JZ4740)+= 0xffffffff80010000' I added that code, but that was mostly cargo-culting |
| 08:46.55 | larsc | no idea why and if the ff's are needed |
| 08:47.15 | eintopf | maybe simple don't use uImage |
| 08:48.07 | eintopf | no, that's all a hack :) |
| 08:48.29 | eintopf | then you could use maybe raw format and compile in this address |
| 08:50.49 | larsc | "< _Ralf_> Because binutils will be unhappy otherwise." |
| 08:53.19 | whitequark | Ralf Baechle's still linux-mipsing? |
| 08:54.13 | larsc | yes |
| 09:15.12 | pcercuei | well the ff's break the build on 32-bit systems |
| 09:15.47 | DocScrutinizer05 | err, aiui you extend the hex value form 0x80010000 to 0xffffffff80010000 ? The error is obvious, it's an address, no? so even with most significant bit=1 you should extend it with 0b0 and not 0b1, IOW 0x0000000080010000 |
| 09:16.25 | DocScrutinizer05 | since that's unsigned |
| 09:17.02 | *** join/#qi-hardware FDCX (~fdcx@2a02:2f0a:a03f:ffff::bc19:9247) |
| 09:18.15 | whitequark | oh i recall that ff debacle |
| 09:18.25 | whitequark | the fix is somewhere in my tree from many years ago |
| 09:22.19 | larsc | patches or it didn't happen |
| 09:22.25 | DocScrutinizer05 | meh |
| 09:22.47 | DocScrutinizer05 | patches larsc's notion about addresses being signed values |
| 09:22.55 | DocScrutinizer05 | ;-) |
| 09:24.14 | DocScrutinizer05 | 0xffffffff80010000 is either negative (pretty meaningless for an addr), or an extremely large bytecount which is for sure incorrect |
| 09:25.56 | DocScrutinizer05 | wonders... |
| 09:26.01 | pcercuei | sounds like (int64_t) (int32_t) addr |
| 09:26.04 | DocScrutinizer05 | ~0xffffffff80010000 + 1 |
| 09:26.53 | DocScrutinizer05 | pcercuei: typecast? |
| 09:27.05 | pcercuei | yes |
| 09:27.11 | DocScrutinizer05 | uint then |
| 09:27.27 | DocScrutinizer05 | unless you meant that's the bug |
| 09:27.28 | whitequark | larsc: https://gitorious.org/vogoplayer-tools/xz0032-linux/commit/5ea87f50d937e450c5106ed4b990353c8cd4f82f |
| 09:27.56 | pcercuei | if you use uint then you don't have sign extension |
| 09:27.59 | whitequark | i guess i never built it on a 64-bit machine |
| 09:28.01 | pcercuei | from 32 -> 64 |
| 09:28.14 | DocScrutinizer05 | what is exactly the right thing to do for address |
| 09:28.56 | DocScrutinizer05 | addr is unsigned, there are no negative addresses |
| 09:29.18 | DocScrutinizer05 | which is exactly my point in all of the above |
| 09:30.09 | pcercuei | yes, that's why it doesn't make sense to use f's |
| 09:31.44 | DocScrutinizer05 | exactly :-D |
| 09:32.35 | DocScrutinizer05 | https://github.com/gcwnow/linux/blob/jz-3.19/arch/mips/jz4770/Platform#L3 sounds like an overflow issue when the tool tries to read in a int <0 as uint |
| 09:32.59 | DocScrutinizer05 | prolly a sleeping bug "elsewhere" |
| 09:33.29 | DocScrutinizer05 | the root cause is uint vs int |
| 09:34.07 | pcercuei | yes |
| 09:34.11 | whitequark | amazing, you've been describing the obvious for fifteen minutes |
| 09:34.33 | DocScrutinizer05 | yeah |
| 09:35.03 | DocScrutinizer05 | since it seemed like we had a dispute which actually we didn't have |
| 09:36.49 | DocScrutinizer05 | note that this "elsewhere" code probably worked fine for all load addr < 0x80000000 |
| 10:01.05 | *** join/#qi-hardware jekhor__ (~jek@nat-minsk-pool-46-53-200-107.telecom.by) |
| 10:06.08 | *** join/#qi-hardware paul_boddie (~paul_bodd@cm-84.215.167.166.getinternet.no) |
| 10:10.29 | paul_boddie | mkimage is fine with 0x80001000, so I guess some 64-bit goodness has leaked out throughout that part of the kernel sources. |
| 10:22.11 | larsc | yes |
| 10:23.56 | paul_boddie | I was going to blame the ARM people for being too enthusiastic, now that they've got their arm64. ;-) |
| 10:25.31 | larsc | all the f's should be removed from the address before passing it to mkimage |
| 10:26.18 | paul_boddie | Yes. For now, given that I don't understand why they are there to start with, I'll just build the image separately, OpenWrt-style. |
| 10:26.53 | paul_boddie | I have to say that it is refreshing to have cross-toolchains in Debian, though. :-) |
| 10:33.33 | larsc | paul_boddie: btw. most of the jz4730 peripherals are compatible to the jz4740 peripherals |
| 10:33.54 | larsc | GPIO is one of the few that is different iirc |
| 10:34.38 | paul_boddie | Thanks! I was looking at a device with only an old (2.6!) kernel that uses the jz4730. |
| 10:37.18 | *** join/#qi-hardware jwhitmore (~jwhitmore@88.151.80.134) |
| 10:41.22 | paul_boddie | If I understand correctly, it seems to use PWM via some register that isn't defined in jz4740 as far as I can tell. |
| 10:51.11 | paul_boddie | Ignoring differences in the address bases (0xB0000000 versus 0x10000000) between kernels, it looks like the PWM registers in the jz4730 live where the LCD registers are in the jz4740. |
| 10:56.42 | *** join/#qi-hardware dandon_ (~dandon@88.151.72.40) |
| 11:00.19 | *** join/#qi-hardware jwhitmore (~jwhitmore@88.151.80.134) |
| 11:01.02 | *** join/#qi-hardware jwhitmore_ (~jwhitmore@88.151.80.134) |
| 11:13.13 | paul_boddie | Ah, actually the PWM registers are in a region that appears unassigned on the jz4740. |
| 11:17.16 | DocScrutinizer05 | that sounds odd |
| 11:22.13 | paul_boddie | Well, I'm still getting to grips with understanding header files. I haven't found any actual documentation for this stuff. |
| 11:25.30 | paul_boddie | The jz4730 device is actually one of Nikolaus's side-projects: http://projects.goldelico.com/p/letux-400/ |
| 11:26.27 | paul_boddie | But I also intend to look at other jz-series devices. Wasn't the Dingoo A320 a jz4730 device, too? |
| 11:26.56 | larsc | dingoo is 4740 |
| 11:42.45 | *** join/#qi-hardware jwhitmore_ (~jwhitmore@88.151.80.134) |
| 11:46.00 | *** join/#qi-hardware jekhor__ (~jek@91.215.176.168) |
| 12:59.16 | paul_boddie | Well, rebuilt the kernel for NanoNote, having done "make mrproper" first (with all the right env. variables - sigh), and it hangs after "Starting kernel ...". |
| 12:59.38 | paul_boddie | This is with the OpenWrt patches for 3.18 applied. |
| 13:02.11 | *** join/#qi-hardware jwhitmore_ (~jwhitmore@88.151.80.134) |
| 13:05.25 | larsc | if it hangs at starting kernel the load address is probably wrong |
| 13:06.12 | paul_boddie | I ran mkimage explicitly with the 0x80010000 address, and 0x803f78a0 entry point. |
| 13:15.00 | paul_boddie | But maybe the 0xffffffff80010000 has infected various build products in some way. |
| 13:47.43 | *** join/#qi-hardware sb0 (~sb0@123202036015.ctinets.com) |
| 15:04.17 | paul_boddie | OK, changing the Platform file to use 0x80010000, coercing the uImage target, and doing make uImage produces a bootable kernel again. |
| 15:04.36 | paul_boddie | And the backlight works! :-) |
| 15:11.49 | paul_boddie | But the keymap seems messed up. :-( |
| 15:12.33 | kyak | there was another patch for keymap i think |
| 15:23.10 | paul_boddie | I thought it would be correct in the qi_lb60 board file, though. |
| 15:28.35 | larsc | last time I checked it worked |
| 15:36.57 | paul_boddie | OK, maybe another mistake of mine, perhaps. |
| 15:38.44 | paul_boddie | I think there's some odd interaction between fn and the console, though, in that playing with fn managed to change the keymap and the character set. |
| 15:39.21 | larsc | uart rx is connected to one of the gpios used by the keyboard |
| 15:39.32 | paul_boddie | In another console, it's fine, but shift and fn don't work. |
| 15:39.37 | larsc | so if you are using the serial you don't get all the keys |
| 15:39.53 | paul_boddie | No, this is on the actual keyboard, and the Ben isn't attached to anything. |
| 15:40.54 | *** join/#qi-hardware jekhor__ (~jek@port-174-adslby-pool37.infonet.by) |
| 16:05.33 | kyak | http://projects.qi-hardware.com/index.php/p/openwrt-xburst/source/tree/master/target/linux/xburst/patches-3.3/700-Ben-NanoNote-modifier-keys.patch |
| 16:05.36 | kyak | this one |
| 16:25.58 | paul_boddie | Thanks! I guess that one is tricky to get upstream. |
| 16:26.36 | kyak | and by the way you have to look at all othe patches in target/linux/xburst/patches-3.3 |
| 16:26.53 | kyak | i'm not sure which of them are upstream |
| 16:27.11 | larsc | pretty much all |
| 16:27.20 | kyak | ok, which are not? :) |
| 16:28.13 | larsc | the lcd driver |
| 16:37.59 | paul_boddie | I found some jz4730 patches: http://www.linux-mips.org/archives/linux-mips/2010-02/msg00243.html |
| 16:40.46 | pcercuei | the pinctrl driver :) |
| 16:42.13 | larsc | that was 5 years ago? time flies! |
| 16:46.11 | paul_boddie | That's the problem with Linux: patches become obsolete within weeks! |
| 16:50.27 | paul_boddie | Well, the keymap seems to work now. Thanks again, kyak! |
| 16:54.09 | kyak | paul_boddie: np! |
| 16:55.34 | paul_boddie | Now to see if I can't hack some kind of jz4730 support in. |
| 16:56.30 | paul_boddie | I saw this for MIPS Creator CI20, but it looks like a messy approach: https://github.com/MIPS/CI20_linux/tree/ci20-v3.18/arch/mips/include/asm/mach-jz4740 |
| 16:57.04 | larsc | no, that's the right approach |
| 16:57.27 | paul_boddie | Meanwhile, there's this in gcwzero/linux: https://github.com/gcwnow/linux/tree/jz-3.19/arch/mips/include/asm |
| 16:57.49 | larsc | that's the wrong apprach |
| 16:57.55 | paul_boddie | Both of them set up some extra specific under mach-jz4740. |
| 16:58.28 | paul_boddie | I'm surprised nobody just edited the NanoNote board and related definitions. ;-) |
| 16:59.10 | paul_boddie | Sorry, the former does stuff under mach-jz4740; the latter has its own mach-jz4770. |
| 16:59.50 | paul_boddie | So, I guess augmenting mach-jz4740 is better. |
| 17:02.52 | larsc | yes |
| 17:05.35 | paul_boddie | I should do a survey of how people do this and write an article for LWN about it. ;-) |
| 17:06.55 | paul_boddie | I also saw these jz4750 patches: http://www.linux-mips.org/archives/linux-mips/2012-10/msg00157.html |
| 19:21.23 | *** join/#qi-hardware pcercuei (~pcercuei@2a02:810d:1b40:1118::9) |
| 19:33.55 | *** join/#qi-hardware pcercuei (~pcercuei@2a02:810d:1b40:1118::9) |
| 19:42.47 | *** join/#qi-hardware jwhitmore_ (~jwhitmore@109.79.176.204) |
| 19:53.36 | eintopf | http://distrowatch.com/weekly.php?issue=20150330#community |
| 20:17.16 | paul_boddie | "Soon we will not need dozens of separate userland components talking with an alien kernel." |
| 20:17.30 | paul_boddie | "We will be running just one program!" |
| 20:17.39 | paul_boddie | OK, I made that second quote up. ;-) |
| 20:34.30 | *** join/#qi-hardware pcercuei (~pcercuei@2a02:810d:1b40:1118::9) |
| 21:09.21 | *** join/#qi-hardware jekhor__ (~jek@nat-minsk-pool-46-53-200-107.telecom.by) |
| 21:52.40 | paul_boddie | (jz4730) It looks like the GPIO for PWM is different to the jz4740, which might make using the PWM driver awkward. |
| 22:08.53 | *** join/#qi-hardware uwe_ (~uwe_@ipservice-092-211-198-029.092.211.pools.vodafone-ip.de) |
| 22:44.23 | *** join/#qi-hardware jwhitmore_ (~jwhitmore@109.79.176.204) |
| 23:35.29 | *** join/#qi-hardware jwhitmore_ (~jwhitmore@109.79.176.204) |