<eintopf>
also check if params.addr is really a 64 bit type
<eintopf>
:|
<eintopf>
and if this is not a 64 bit type then I think they need a new format for uImage
<eintopf>
that's maybe the reason why they don't support 64 bit addresses yet
<eintopf>
if this is true, it's terrible to fix it
<larsc>
or fix the kernel to not add the extra 0xff... since this is a 32-bit processor anyway
<eintopf>
yep
<larsc>
'load-$(CONFIG_MACH_JZ4740)+= 0xffffffff80010000' I added that code, but that was mostly cargo-culting
<larsc>
no idea why and if the ff's are needed
<eintopf>
maybe simple don't use uImage
<eintopf>
no, that's all a hack :)
<eintopf>
then you could use maybe raw format and compile in this address
<larsc>
"< _Ralf_> Because binutils will be unhappy otherwise."
<whitequark>
Ralf Baechle's still linux-mipsing?
<larsc>
yes
FDCX has quit [Read error: Connection reset by peer]
<pcercuei>
well the ff's break the build on 32-bit systems
<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
<DocScrutinizer05>
since that's unsigned
FDCX has joined #qi-hardware
<whitequark>
oh i recall that ff debacle
<whitequark>
the fix is somewhere in my tree from many years ago
<larsc>
patches or it didn't happen
<DocScrutinizer05>
meh
* DocScrutinizer05
patches larsc's notion about addresses being signed values
<DocScrutinizer05>
;-)
<DocScrutinizer05>
0xffffffff80010000 is either negative (pretty meaningless for an addr), or an extremely large bytecount which is for sure incorrect
* DocScrutinizer05
wonders...
<pcercuei>
sounds like (int64_t) (int32_t) addr
<DocScrutinizer05>
~0xffffffff80010000 + 1
<DocScrutinizer05>
pcercuei: typecast?
<pcercuei>
yes
<DocScrutinizer05>
uint then
<DocScrutinizer05>
unless you meant that's the bug
<DocScrutinizer05>
prolly a sleeping bug "elsewhere"
<DocScrutinizer05>
the root cause is uint vs int
<pcercuei>
yes
<whitequark>
amazing, you've been describing the obvious for fifteen minutes
<DocScrutinizer05>
yeah
<DocScrutinizer05>
since it seemed like we had a dispute which actually we didn't have
<DocScrutinizer05>
note that this "elsewhere" code probably worked fine for all load addr < 0x80000000
jekhor__ has quit [Read error: Connection reset by peer]
jekhor__ has joined #qi-hardware
paul_boddie has joined #qi-hardware
<paul_boddie>
mkimage is fine with 0x80001000, so I guess some 64-bit goodness has leaked out throughout that part of the kernel sources.
atommann has quit [Quit: Leaving]
<larsc>
yes
<paul_boddie>
I was going to blame the ARM people for being too enthusiastic, now that they've got their arm64. ;-)
<larsc>
all the f's should be removed from the address before passing it to mkimage
<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.
<paul_boddie>
I have to say that it is refreshing to have cross-toolchains in Debian, though. :-)
<larsc>
paul_boddie: btw. most of the jz4730 peripherals are compatible to the jz4740 peripherals
<larsc>
GPIO is one of the few that is different iirc
<paul_boddie>
Thanks! I was looking at a device with only an old (2.6!) kernel that uses the jz4730.
jwhitmore has joined #qi-hardware
<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.
jwhitmore has quit [Ping timeout: 252 seconds]
<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.
dandon_ has joined #qi-hardware
dandon has quit [Ping timeout: 265 seconds]
dandon_ is now known as dandon
jekhor__ has quit [Ping timeout: 250 seconds]
jwhitmore has joined #qi-hardware
jwhitmore_ has joined #qi-hardware
jwhitmore has quit [Ping timeout: 248 seconds]
jwhitmore_ has quit [Ping timeout: 255 seconds]
<paul_boddie>
Ah, actually the PWM registers are in a region that appears unassigned on the jz4740.
<DocScrutinizer05>
that sounds odd
<paul_boddie>
Well, I'm still getting to grips with understanding header files. I haven't found any actual documentation for this stuff.
<paul_boddie>
But I also intend to look at other jz-series devices. Wasn't the Dingoo A320 a jz4730 device, too?
<larsc>
dingoo is 4740
fengling has quit [Ping timeout: 265 seconds]
jwhitmore_ has joined #qi-hardware
jekhor__ has joined #qi-hardware
jwhitmore_ has quit [Ping timeout: 256 seconds]
<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 ...".
<paul_boddie>
This is with the OpenWrt patches for 3.18 applied.
jwhitmore_ has joined #qi-hardware
<larsc>
if it hangs at starting kernel the load address is probably wrong
<paul_boddie>
I ran mkimage explicitly with the 0x80010000 address, and 0x803f78a0 entry point.
jwhitmore_ has quit [Ping timeout: 265 seconds]
<paul_boddie>
But maybe the 0xffffffff80010000 has infected various build products in some way.
sb0 has quit [Quit: Leaving]
sb0 has joined #qi-hardware
jekhor__ has quit [Ping timeout: 264 seconds]
<paul_boddie>
OK, changing the Platform file to use 0x80010000, coercing the uImage target, and doing make uImage produces a bootable kernel again.
<paul_boddie>
And the backlight works! :-)
<paul_boddie>
But the keymap seems messed up. :-(
<kyak>
there was another patch for keymap i think
<paul_boddie>
I thought it would be correct in the qi_lb60 board file, though.
<larsc>
last time I checked it worked
<paul_boddie>
OK, maybe another mistake of mine, perhaps.
<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.
<larsc>
uart rx is connected to one of the gpios used by the keyboard
<paul_boddie>
In another console, it's fine, but shift and fn don't work.
<larsc>
so if you are using the serial you don't get all the keys
<paul_boddie>
No, this is on the actual keyboard, and the Ben isn't attached to anything.