2015-03-30 00:27 jwhitmore has quit [Ping timeout: 250 seconds] 2015-03-30 01:34 fengling has joined #qi-hardware 2015-03-30 01:52 Atomic_9eHcd has joined #qi-hardware 2015-03-30 02:07 atommann has joined #qi-hardware 2015-03-30 02:26 wpwrak has quit [Ping timeout: 252 seconds] 2015-03-30 02:31 wpwrak has joined #qi-hardware 2015-03-30 02:31 xiangfu has joined #qi-hardware 2015-03-30 03:11 Atomic_9eHcd has quit [Quit: AtomicIRC: The nuclear option.] 2015-03-30 04:01 atommann has quit [Ping timeout: 255 seconds] 2015-03-30 04:13 sb0 has joined #qi-hardware 2015-03-30 04:46 atommann has joined #qi-hardware 2015-03-30 05:50 porchaso0 has quit [Quit: Leaving...] 2015-03-30 05:56 porchao has joined #qi-hardware 2015-03-30 06:57 jekhor has joined #qi-hardware 2015-03-30 07:05 0xffffffff80010000 to 0xffffffff (seems like a strtoul instead strtoull) or something like that :) 2015-03-30 07:31 jekhor_ has joined #qi-hardware 2015-03-30 07:35 jekhor has quit [Ping timeout: 264 seconds] 2015-03-30 07:36 xiangfu has quit [Remote host closed the connection] 2015-03-30 07:38 http://git.denx.de/?p=u-boot.git;a=blob;f=tools/mkimage.c#l87 2015-03-30 07:48 sb0 has quit [Quit: Leaving] 2015-03-30 07:49 sb0 has joined #qi-hardware 2015-03-30 07:51 jekhor__ has joined #qi-hardware 2015-03-30 07:55 jekhor_ has quit [Ping timeout: 248 seconds] 2015-03-30 07:56 wolfspraul has joined #qi-hardware 2015-03-30 08:01 pcercuei has joined #qi-hardware 2015-03-30 08:36 grml, barebox has the 1:1 tool from u-boot 2015-03-30 08:36 so if somebody want to fix that, please cc barebox@lists.infradead.org 2015-03-30 08:38 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 2015-03-30 08:41 also check if params.addr is really a 64 bit type 2015-03-30 08:41 :| 2015-03-30 08:43 and if this is not a 64 bit type then I think they need a new format for uImage 2015-03-30 08:43 that's maybe the reason why they don't support 64 bit addresses yet 2015-03-30 08:44 if this is true, it's terrible to fix it 2015-03-30 08:44 or fix the kernel to not add the extra 0xff... since this is a 32-bit processor anyway 2015-03-30 08:44 yep 2015-03-30 08:46 'load-$(CONFIG_MACH_JZ4740)+= 0xffffffff80010000' I added that code, but that was mostly cargo-culting 2015-03-30 08:46 no idea why and if the ff's are needed 2015-03-30 08:47 maybe simple don't use uImage 2015-03-30 08:48 no, that's all a hack :) 2015-03-30 08:48 then you could use maybe raw format and compile in this address 2015-03-30 08:50 "< _Ralf_> Because binutils will be unhappy otherwise." 2015-03-30 08:53 Ralf Baechle's still linux-mipsing? 2015-03-30 08:54 yes 2015-03-30 09:02 FDCX has quit [Read error: Connection reset by peer] 2015-03-30 09:15 well the ff's break the build on 32-bit systems 2015-03-30 09:15 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 2015-03-30 09:16 since that's unsigned 2015-03-30 09:17 FDCX has joined #qi-hardware 2015-03-30 09:18 oh i recall that ff debacle 2015-03-30 09:18 the fix is somewhere in my tree from many years ago 2015-03-30 09:22 patches or it didn't happen 2015-03-30 09:22 meh 2015-03-30 09:22 * DocScrutinizer05 patches larsc's notion about addresses being signed values 2015-03-30 09:22 ;-) 2015-03-30 09:24 0xffffffff80010000 is either negative (pretty meaningless for an addr), or an extremely large bytecount which is for sure incorrect 2015-03-30 09:25 * DocScrutinizer05 wonders... 2015-03-30 09:26 sounds like (int64_t) (int32_t) addr 2015-03-30 09:26 ~0xffffffff80010000 + 1 2015-03-30 09:26 pcercuei: typecast? 2015-03-30 09:27 yes 2015-03-30 09:27 uint then 2015-03-30 09:27 unless you meant that's the bug 2015-03-30 09:27 larsc: https://gitorious.org/vogoplayer-tools/xz0032-linux/commit/5ea87f50d937e450c5106ed4b990353c8cd4f82f 2015-03-30 09:27 if you use uint then you don't have sign extension 2015-03-30 09:27 i guess i never built it on a 64-bit machine 2015-03-30 09:28 from 32 -> 64 2015-03-30 09:28 what is exactly the right thing to do for address 2015-03-30 09:28 addr is unsigned, there are no negative addresses 2015-03-30 09:29 which is exactly my point in all of the above 2015-03-30 09:30 yes, that's why it doesn't make sense to use f's 2015-03-30 09:31 exactly :-D 2015-03-30 09:32 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 2015-03-30 09:32 prolly a sleeping bug "elsewhere" 2015-03-30 09:33 the root cause is uint vs int 2015-03-30 09:34 yes 2015-03-30 09:34 amazing, you've been describing the obvious for fifteen minutes 2015-03-30 09:34 yeah 2015-03-30 09:35 since it seemed like we had a dispute which actually we didn't have 2015-03-30 09:36 note that this "elsewhere" code probably worked fine for all load addr < 0x80000000 2015-03-30 10:00 jekhor__ has quit [Read error: Connection reset by peer] 2015-03-30 10:01 jekhor__ has joined #qi-hardware 2015-03-30 10:06 paul_boddie has joined #qi-hardware 2015-03-30 10:10 mkimage is fine with 0x80001000, so I guess some 64-bit goodness has leaked out throughout that part of the kernel sources. 2015-03-30 10:15 atommann has quit [Quit: Leaving] 2015-03-30 10:22 yes 2015-03-30 10:23 I was going to blame the ARM people for being too enthusiastic, now that they've got their arm64. ;-) 2015-03-30 10:25 all the f's should be removed from the address before passing it to mkimage 2015-03-30 10:26 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. 2015-03-30 10:26 I have to say that it is refreshing to have cross-toolchains in Debian, though. :-) 2015-03-30 10:33 paul_boddie: btw. most of the jz4730 peripherals are compatible to the jz4740 peripherals 2015-03-30 10:33 GPIO is one of the few that is different iirc 2015-03-30 10:34 Thanks! I was looking at a device with only an old (2.6!) kernel that uses the jz4730. 2015-03-30 10:37 jwhitmore has joined #qi-hardware 2015-03-30 10:41 If I understand correctly, it seems to use PWM via some register that isn't defined in jz4740 as far as I can tell. 2015-03-30 10:46 jwhitmore has quit [Ping timeout: 252 seconds] 2015-03-30 10:51 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. 2015-03-30 10:56 dandon_ has joined #qi-hardware 2015-03-30 10:58 dandon has quit [Ping timeout: 265 seconds] 2015-03-30 10:58 dandon_ is now known as dandon 2015-03-30 10:59 jekhor__ has quit [Ping timeout: 250 seconds] 2015-03-30 11:00 jwhitmore has joined #qi-hardware 2015-03-30 11:01 jwhitmore_ has joined #qi-hardware 2015-03-30 11:04 jwhitmore has quit [Ping timeout: 248 seconds] 2015-03-30 11:07 jwhitmore_ has quit [Ping timeout: 255 seconds] 2015-03-30 11:13 Ah, actually the PWM registers are in a region that appears unassigned on the jz4740. 2015-03-30 11:17 that sounds odd 2015-03-30 11:22 Well, I'm still getting to grips with understanding header files. I haven't found any actual documentation for this stuff. 2015-03-30 11:25 The jz4730 device is actually one of Nikolaus's side-projects: http://projects.goldelico.com/p/letux-400/ 2015-03-30 11:26 But I also intend to look at other jz-series devices. Wasn't the Dingoo A320 a jz4730 device, too? 2015-03-30 11:26 dingoo is 4740 2015-03-30 11:36 fengling has quit [Ping timeout: 265 seconds] 2015-03-30 11:42 jwhitmore_ has joined #qi-hardware 2015-03-30 11:46 jekhor__ has joined #qi-hardware 2015-03-30 11:48 jwhitmore_ has quit [Ping timeout: 256 seconds] 2015-03-30 12:59 Well, rebuilt the kernel for NanoNote, having done "make mrproper" first (with all the right env. variables - sigh), and it hangs after "Starting kernel ...". 2015-03-30 12:59 This is with the OpenWrt patches for 3.18 applied. 2015-03-30 13:02 jwhitmore_ has joined #qi-hardware 2015-03-30 13:05 if it hangs at starting kernel the load address is probably wrong 2015-03-30 13:06 I ran mkimage explicitly with the 0x80010000 address, and 0x803f78a0 entry point. 2015-03-30 13:08 jwhitmore_ has quit [Ping timeout: 265 seconds] 2015-03-30 13:15 But maybe the 0xffffffff80010000 has infected various build products in some way. 2015-03-30 13:43 sb0 has quit [Quit: Leaving] 2015-03-30 13:47 sb0 has joined #qi-hardware 2015-03-30 14:44 jekhor__ has quit [Ping timeout: 264 seconds] 2015-03-30 15:04 OK, changing the Platform file to use 0x80010000, coercing the uImage target, and doing make uImage produces a bootable kernel again. 2015-03-30 15:04 And the backlight works! :-) 2015-03-30 15:11 But the keymap seems messed up. :-( 2015-03-30 15:12 there was another patch for keymap i think 2015-03-30 15:23 I thought it would be correct in the qi_lb60 board file, though. 2015-03-30 15:28 last time I checked it worked 2015-03-30 15:36 OK, maybe another mistake of mine, perhaps. 2015-03-30 15:38 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. 2015-03-30 15:39 uart rx is connected to one of the gpios used by the keyboard 2015-03-30 15:39 In another console, it's fine, but shift and fn don't work. 2015-03-30 15:39 so if you are using the serial you don't get all the keys 2015-03-30 15:39 No, this is on the actual keyboard, and the Ben isn't attached to anything. 2015-03-30 15:40 jekhor__ has joined #qi-hardware 2015-03-30 16:05 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 2015-03-30 16:05 this one 2015-03-30 16:25 Thanks! I guess that one is tricky to get upstream. 2015-03-30 16:26 and by the way you have to look at all othe patches in target/linux/xburst/patches-3.3 2015-03-30 16:26 i'm not sure which of them are upstream 2015-03-30 16:27 pretty much all 2015-03-30 16:27 ok, which are not? :) 2015-03-30 16:28 the lcd driver 2015-03-30 16:37 I found some jz4730 patches: http://www.linux-mips.org/archives/linux-mips/2010-02/msg00243.html 2015-03-30 16:40 the pinctrl driver :) 2015-03-30 16:42 that was 5 years ago? time flies! 2015-03-30 16:46 That's the problem with Linux: patches become obsolete within weeks! 2015-03-30 16:50 Well, the keymap seems to work now. Thanks again, kyak! 2015-03-30 16:52 pcercuei has quit [Ping timeout: 272 seconds] 2015-03-30 16:54 paul_boddie: np! 2015-03-30 16:55 Now to see if I can't hack some kind of jz4730 support in. 2015-03-30 16:56 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 2015-03-30 16:57 no, that's the right approach 2015-03-30 16:57 Meanwhile, there's this in gcwzero/linux: https://github.com/gcwnow/linux/tree/jz-3.19/arch/mips/include/asm 2015-03-30 16:57 that's the wrong apprach 2015-03-30 16:57 sb0 has quit [Quit: Leaving] 2015-03-30 16:57 Both of them set up some extra specific under mach-jz4740. 2015-03-30 16:58 I'm surprised nobody just edited the NanoNote board and related definitions. ;-) 2015-03-30 16:58 jekhor__ has quit [Ping timeout: 248 seconds] 2015-03-30 16:59 Sorry, the former does stuff under mach-jz4740; the latter has its own mach-jz4770. 2015-03-30 16:59 So, I guess augmenting mach-jz4740 is better. 2015-03-30 17:02 yes 2015-03-30 17:05 I should do a survey of how people do this and write an article for LWN about it. ;-) 2015-03-30 17:06 I also saw these jz4750 patches: http://www.linux-mips.org/archives/linux-mips/2012-10/msg00157.html 2015-03-30 19:21 pcercuei has joined #qi-hardware 2015-03-30 19:30 pcercuei has quit [Quit: Lost terminal] 2015-03-30 19:33 pcercuei has joined #qi-hardware 2015-03-30 19:42 jwhitmore_ has joined #qi-hardware 2015-03-30 19:53 http://distrowatch.com/weekly.php?issue=20150330#community 2015-03-30 20:17 "Soon we will not need dozens of separate userland components talking with an alien kernel." 2015-03-30 20:17 "We will be running just one program!" 2015-03-30 20:17 OK, I made that second quote up. ;-) 2015-03-30 20:33 pcercuei has quit [Ping timeout: 252 seconds] 2015-03-30 20:34 pcercuei has joined #qi-hardware 2015-03-30 21:09 jekhor__ has joined #qi-hardware 2015-03-30 21:14 pcercuei has quit [Ping timeout: 256 seconds] 2015-03-30 21:24 wolfspraul has quit [Ping timeout: 252 seconds] 2015-03-30 21:52 (jz4730) It looks like the GPIO for PWM is different to the jz4740, which might make using the PWM driver awkward. 2015-03-30 22:08 uwe_ has quit [Ping timeout: 252 seconds] 2015-03-30 22:08 uwe_ has joined #qi-hardware 2015-03-30 22:15 jekhor__ has quit [Ping timeout: 256 seconds] 2015-03-30 22:35 jwhitmore_ has quit [Ping timeout: 250 seconds] 2015-03-30 22:43 paul_boddie has quit [] 2015-03-30 22:44 jwhitmore_ has joined #qi-hardware 2015-03-30 23:21 jwhitmore_ has quit [Ping timeout: 248 seconds] 2015-03-30 23:35 jwhitmore_ has joined #qi-hardware 2015-03-30 23:54 jwhitmore_ has quit [Ping timeout: 256 seconds]