#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

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