DocScrutinizer05 changed the topic of #qi-hardware to: Copyleft hardware - http://qi-hardware.com | hardware hackers join here to discuss Ben NanoNote, atben / atusb 802.15.4 wireless, and other community driven hw projects | public logging at http://en.qi-hardware.com/irclogs and http://irclog.whitequark.org/qi-hardware
jwhitmore has quit [Ping timeout: 250 seconds]
fengling has joined #qi-hardware
Atomic_9eHcd has joined #qi-hardware
atommann has joined #qi-hardware
wpwrak has quit [Ping timeout: 252 seconds]
wpwrak has joined #qi-hardware
xiangfu has joined #qi-hardware
Atomic_9eHcd has quit [Quit: AtomicIRC: The nuclear option.]
atommann has quit [Ping timeout: 255 seconds]
sb0 has joined #qi-hardware
atommann has joined #qi-hardware
porchaso0 has quit [Quit: Leaving...]
porchao has joined #qi-hardware
jekhor has joined #qi-hardware
<eintopf> 0xffffffff80010000 to 0xffffffff (seems like a strtoul instead strtoull) or something like that :)
jekhor_ has joined #qi-hardware
jekhor has quit [Ping timeout: 264 seconds]
xiangfu has quit [Remote host closed the connection]
sb0 has quit [Quit: Leaving]
sb0 has joined #qi-hardware
jekhor__ has joined #qi-hardware
jekhor_ has quit [Ping timeout: 248 seconds]
wolfspraul has joined #qi-hardware
pcercuei has joined #qi-hardware
<eintopf> grml, barebox has the 1:1 tool from u-boot
<eintopf> so if somebody want to fix that, please cc barebox@lists.infradead.org
<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
<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
<pcercuei> if you use uint then you don't have sign extension
<whitequark> i guess i never built it on a 64-bit machine
<pcercuei> from 32 -> 64
<DocScrutinizer05> what is exactly the right thing to do for address
<DocScrutinizer05> addr is unsigned, there are no negative addresses
<DocScrutinizer05> which is exactly my point in all of the above
<pcercuei> yes, that's why it doesn't make sense to use f's
<DocScrutinizer05> exactly :-D
<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
<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> The jz4730 device is actually one of Nikolaus's side-projects: http://projects.goldelico.com/p/letux-400/
<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.
jekhor__ has joined #qi-hardware
<kyak> this one
<paul_boddie> Thanks! I guess that one is tricky to get upstream.
<kyak> and by the way you have to look at all othe patches in target/linux/xburst/patches-3.3
<kyak> i'm not sure which of them are upstream
<larsc> pretty much all
<kyak> ok, which are not? :)
<larsc> the lcd driver
<pcercuei> the pinctrl driver :)
<larsc> that was 5 years ago? time flies!
<paul_boddie> That's the problem with Linux: patches become obsolete within weeks!
<paul_boddie> Well, the keymap seems to work now. Thanks again, kyak!
pcercuei has quit [Ping timeout: 272 seconds]
<kyak> paul_boddie: np!
<paul_boddie> Now to see if I can't hack some kind of jz4730 support in.
<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
<larsc> no, that's the right approach
<paul_boddie> Meanwhile, there's this in gcwzero/linux: https://github.com/gcwnow/linux/tree/jz-3.19/arch/mips/include/asm
<larsc> that's the wrong apprach
sb0 has quit [Quit: Leaving]
<paul_boddie> Both of them set up some extra specific under mach-jz4740.
<paul_boddie> I'm surprised nobody just edited the NanoNote board and related definitions. ;-)
jekhor__ has quit [Ping timeout: 248 seconds]
<paul_boddie> Sorry, the former does stuff under mach-jz4740; the latter has its own mach-jz4770.
<paul_boddie> So, I guess augmenting mach-jz4740 is better.
<larsc> yes
<paul_boddie> I should do a survey of how people do this and write an article for LWN about it. ;-)
<paul_boddie> I also saw these jz4750 patches: http://www.linux-mips.org/archives/linux-mips/2012-10/msg00157.html
pcercuei has joined #qi-hardware
pcercuei has quit [Quit: Lost terminal]
pcercuei has joined #qi-hardware
jwhitmore_ has joined #qi-hardware
<paul_boddie> "Soon we will not need dozens of separate userland components talking with an alien kernel."
<paul_boddie> "We will be running just one program!"
<paul_boddie> OK, I made that second quote up. ;-)
pcercuei has quit [Ping timeout: 252 seconds]
pcercuei has joined #qi-hardware
jekhor__ has joined #qi-hardware
pcercuei has quit [Ping timeout: 256 seconds]
wolfspraul has quit [Ping timeout: 252 seconds]
<paul_boddie> (jz4730) It looks like the GPIO for PWM is different to the jz4740, which might make using the PWM driver awkward.
uwe_ has quit [Ping timeout: 252 seconds]
uwe_ has joined #qi-hardware
jekhor__ has quit [Ping timeout: 256 seconds]
jwhitmore_ has quit [Ping timeout: 250 seconds]
paul_boddie has quit []
jwhitmore_ has joined #qi-hardware
jwhitmore_ has quit [Ping timeout: 248 seconds]
jwhitmore_ has joined #qi-hardware
jwhitmore_ has quit [Ping timeout: 256 seconds]