#qi-hardware IRC log for Monday, 2015-03-30

eintopf0xffffffff80010000 to 0xffffffff (seems like a strtoul instead strtoull) or something like that :)07:05
larschttp://git.denx.de/?p=u-boot.git;a=blob;f=tools/mkimage.c#l8707:38
eintopfgrml, barebox has the 1:1 tool from u-boot08:36
eintopfso if somebody want to fix that, please cc barebox@lists.infradead.org08:36
eintopfhttp://git.pengutronix.de/?p=barebox.git;a=blob;f=scripts/mkimage.c#l346 - yea, patch would not apply but the maintainer will deal with that08:38
eintopfalso check if params.addr is really a 64 bit type08:41
eintopf:|08:41
eintopfand if this is not a 64 bit type then I think they need a new format for uImage08:43
eintopfthat's maybe the reason why they don't support 64 bit addresses yet08:43
eintopfif this is true, it's terrible to fix it08:44
larscor fix the kernel to not add the extra 0xff... since this is a 32-bit processor anyway08:44
eintopfyep08:44
larsc'load-$(CONFIG_MACH_JZ4740)+= 0xffffffff80010000' I added that code, but that was mostly cargo-culting08:46
larscno idea why and if the ff's are needed08:46
eintopfmaybe simple don't use uImage08:47
eintopfno, that's all a hack :)08:48
eintopfthen you could use maybe raw format and compile in this address08:48
larsc"< _Ralf_> Because binutils will be unhappy otherwise." 08:50
whitequarkRalf Baechle's still linux-mipsing?08:53
larscyes08:54
pcercueiwell the ff's break the build on 32-bit systems09:15
DocScrutinizer05err, 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 0x000000008001000009:15
DocScrutinizer05since that's unsigned09:16
whitequarkoh i recall that ff debacle09:18
whitequarkthe fix is somewhere in my tree from many years ago09:18
larscpatches or it didn't happen09:22
DocScrutinizer05meh09:22
Action: DocScrutinizer05 patches larsc's notion about addresses being signed values09:22
DocScrutinizer05;-)09:22
DocScrutinizer050xffffffff80010000 is either negative (pretty meaningless for an addr), or an extremely large bytecount which is for sure incorrect09:24
Action: DocScrutinizer05 wonders...09:25
pcercueisounds like (int64_t) (int32_t) addr09:26
DocScrutinizer05~0xffffffff80010000 + 109:26
DocScrutinizer05pcercuei: typecast?09:26
pcercueiyes09:27
DocScrutinizer05uint then09:27
DocScrutinizer05unless you meant that's the bug09:27
whitequarklarsc: https://gitorious.org/vogoplayer-tools/xz0032-linux/commit/5ea87f50d937e450c5106ed4b990353c8cd4f82f09:27
pcercueiif you use uint then you don't have sign extension09:27
whitequarki guess i never built it on a 64-bit machine09:27
pcercueifrom 32 -> 6409:28
DocScrutinizer05what is exactly the right thing to do for address09:28
DocScrutinizer05addr is unsigned, there are no negative addresses09:28
DocScrutinizer05which is exactly my point in all of the above09:29
pcercueiyes, that's why it doesn't make sense to use f's 09:30
DocScrutinizer05exactly :-D09:31
DocScrutinizer05https://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 uint09:32
DocScrutinizer05prolly a sleeping bug "elsewhere"09:32
DocScrutinizer05the root cause is uint vs int 09:33
pcercueiyes09:34
whitequarkamazing, you've been describing the obvious for fifteen minutes09:34
DocScrutinizer05yeah09:34
DocScrutinizer05since it seemed like we had a dispute which actually we didn't have09:35
DocScrutinizer05note that this "elsewhere" code probably worked fine for all load addr < 0x8000000009:36
paul_boddiemkimage is fine with 0x80001000, so I guess some 64-bit goodness has leaked out throughout that part of the kernel sources.10:10
larscyes10:22
paul_boddieI was going to blame the ARM people for being too enthusiastic, now that they've got their arm64. ;-)10:23
larscall the f's should be removed from the address before passing it to mkimage10:25
paul_boddieYes. 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
paul_boddieI have to say that it is refreshing to have cross-toolchains in Debian, though. :-)10:26
larscpaul_boddie: btw. most of the jz4730 peripherals are compatible to the jz4740 peripherals10:33
larscGPIO is one of the few that is different iirc10:33
paul_boddieThanks! I was looking at a device with only an old (2.6!) kernel that uses the jz4730.10:34
paul_boddieIf I understand correctly, it seems to use PWM via some register that isn't defined in jz4740 as far as I can tell.10:41
paul_boddieIgnoring 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:51
paul_boddieAh, actually the PWM registers are in a region that appears unassigned on the jz4740.11:13
DocScrutinizer05that sounds odd11:17
paul_boddieWell, I'm still getting to grips with understanding header files. I haven't found any actual documentation for this stuff.11:22
paul_boddieThe jz4730 device is actually one of Nikolaus's side-projects: http://projects.goldelico.com/p/letux-400/11:25
paul_boddieBut I also intend to look at other jz-series devices. Wasn't the Dingoo A320 a jz4730 device, too?11:26
larscdingoo is 474011:26
paul_boddieWell, 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
paul_boddieThis is with the OpenWrt patches for 3.18 applied.12:59
larscif it hangs at starting kernel the load address is probably wrong13:05
paul_boddieI ran mkimage explicitly with the 0x80010000 address, and 0x803f78a0 entry point.13:06
paul_boddieBut maybe the 0xffffffff80010000 has infected various build products in some way.13:15
paul_boddieOK, changing the Platform file to use 0x80010000, coercing the uImage target, and doing make uImage produces a bootable kernel again.15:04
paul_boddieAnd the backlight works! :-)15:04
paul_boddieBut the keymap seems messed up. :-(15:11
kyakthere was another patch for keymap i think15:12
paul_boddieI thought it would be correct in the qi_lb60 board file, though.15:23
larsclast time I checked it worked15:28
paul_boddieOK, maybe another mistake of mine, perhaps.15:36
paul_boddieI 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:38
larscuart rx is connected to one of the gpios used by the keyboard15:39
paul_boddieIn another console, it's fine, but shift and fn don't work.15:39
larscso if you are using the serial you don't get all the keys15:39
paul_boddieNo, this is on the actual keyboard, and the Ben isn't attached to anything.15:39
kyakhttp://projects.qi-hardware.com/index.php/p/openwrt-xburst/source/tree/master/target/linux/xburst/patches-3.3/700-Ben-NanoNote-modifier-keys.patch16:05
kyakthis one16:05
paul_boddieThanks! I guess that one is tricky to get upstream.16:25
kyakand by the way you have to look at all othe patches in target/linux/xburst/patches-3.316:26
kyaki'm not sure which of them are upstream16:26
larscpretty much all16:27
kyakok, which are not? :)16:27
larscthe lcd driver16:28
paul_boddieI found some jz4730 patches: http://www.linux-mips.org/archives/linux-mips/2010-02/msg00243.html16:37
pcercueithe pinctrl driver :)16:40
larscthat was 5 years ago? time flies!16:42
paul_boddieThat's the problem with Linux: patches become obsolete within weeks!16:46
paul_boddieWell, the keymap seems to work now. Thanks again, kyak!16:50
kyakpaul_boddie: np!16:54
paul_boddieNow to see if I can't hack some kind of jz4730 support in.16:55
paul_boddieI 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-jz474016:56
larscno, that's the right approach16:57
paul_boddieMeanwhile, there's this in gcwzero/linux: https://github.com/gcwnow/linux/tree/jz-3.19/arch/mips/include/asm16:57
larscthat's the wrong apprach16:57
paul_boddieBoth of them set up some extra specific under mach-jz4740.16:57
paul_boddieI'm surprised nobody just edited the NanoNote board and related definitions. ;-)16:58
paul_boddieSorry, the former does stuff under mach-jz4740; the latter has its own mach-jz4770.16:59
paul_boddieSo, I guess augmenting mach-jz4740 is better.16:59
larscyes17:02
paul_boddieI should do a survey of how people do this and write an article for LWN about it. ;-)17:05
paul_boddieI also saw these jz4750 patches: http://www.linux-mips.org/archives/linux-mips/2012-10/msg00157.html17:06
eintopfhttp://distrowatch.com/weekly.php?issue=20150330#community19:53
paul_boddie"Soon we will not need dozens of separate userland components talking with an alien kernel."20:17
paul_boddie"We will be running just one program!"20:17
paul_boddieOK, I made that second quote up. ;-)20:17
paul_boddie(jz4730) It looks like the GPIO for PWM is different to the jz4740, which might make using the PWM driver awkward.21:52
--- Tue Mar 31 201500:00

Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!