2013-09-18 00:26 FDCX_ has quit [Ping timeout: 256 seconds]
2013-09-18 00:31 pcercuei has quit [Quit: dodo]
2013-09-18 00:46 FDCX_ has joined #qi-hardware
2013-09-18 00:46 wej has quit [Ping timeout: 260 seconds]
2013-09-18 00:47 wej has joined #qi-hardware
2013-09-18 01:10 dos1 has quit [Ping timeout: 248 seconds]
2013-09-18 01:13 FDCX_ has quit [Ping timeout: 245 seconds]
2013-09-18 01:30 FDCX_ has joined #qi-hardware
2013-09-18 01:35 FDCX_ has quit [Ping timeout: 260 seconds]
2013-09-18 02:06 xiangfu has joined #qi-hardware
2013-09-18 02:21 xiangfu has quit [Quit: leaving]
2013-09-18 02:21 xiangfu has joined #qi-hardware
2013-09-18 03:11 Jay7x has joined #qi-hardware
2013-09-18 03:13 valhalla_ has joined #qi-hardware
2013-09-18 03:13 valhalla has quit [*.net *.split]
2013-09-18 03:13 Jay7 has quit [*.net *.split]
2013-09-18 03:13 mirko has quit [*.net *.split]
2013-09-18 03:18 mirko has joined #qi-hardware
2013-09-18 06:36 FDCX_ has joined #qi-hardware
2013-09-18 06:36 xiangfu has quit [Ping timeout: 276 seconds]
2013-09-18 06:41 wej has quit [Read error: Connection reset by peer]
2013-09-18 06:44 wej has joined #qi-hardware
2013-09-18 06:47 xiangfu has joined #qi-hardware
2013-09-18 06:54 jekhor has joined #qi-hardware
2013-09-18 07:34 lekernel has joined #qi-hardware
2013-09-18 07:40 wolfspraul has joined #qi-hardware
2013-09-18 07:41 panda|x201 has joined #qi-hardware
2013-09-18 07:47 panda|x201 has quit [Ping timeout: 256 seconds]
2013-09-18 07:52 viric has quit [Quit: ZNC - http://znc.in]
2013-09-18 07:54 viric has joined #qi-hardware
2013-09-18 08:00 panda|x201 has joined #qi-hardware
2013-09-18 08:12 panda|x201 has quit [Ping timeout: 256 seconds]
2013-09-18 09:21 xiangfu has quit [Quit: leaving]
2013-09-18 09:21 xiangfu has joined #qi-hardware
2013-09-18 09:41 rz2k has joined #qi-hardware
2013-09-18 09:44 <apelete> Hello
2013-09-18 09:46 <apelete> has anyuone here tried to debug the Nanonote kernel with kgdb ?
2013-09-18 09:49 <viric> me
2013-09-18 09:50 <viric> apelete: http://viric.name/cgi-bin/nanonixos/doc/trunk/doc/kerneldbg/index.wiki
2013-09-18 09:52 <apelete> I built 3.9 with the following debug options for kgdb:
2013-09-18 09:52 <apelete> # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
2013-09-18 09:52 <apelete> CONFIG_KGDB=y
2013-09-18 09:52 <apelete> CONFIG_KGDB_SERIAL_CONSOLE=y
2013-09-18 09:52 <apelete> CONFIG_MAGIC_SYSRQ=y
2013-09-18 09:52 <apelete> CONFIG_CONSOLE_POLL=y
2013-09-18 09:52 <apelete> CONFIG_FRAME_POINTER=y
2013-09-18 09:52 <apelete> CONFIG_KALLSYMS=y
2013-09-18 09:52 <apelete> CONFIG_KALLSYMS_ALL=y
2013-09-18 09:53 <apelete> but the gdb backtrace output is almost empty, preventing me to debug anything
2013-09-18 09:54 <apelete> viric: you seem to get a correct gdb behaviour, any idea about what I am missing ?
2013-09-18 09:54 <viric> you need a vmlnux with debug info
2013-09-18 09:54 <viric> vmlinux
2013-09-18 09:55 <viric> there is a CONFIG_DEBUG or so
2013-09-18 09:55 <apelete> viric: I flashed the uImage to NN and launched gdb with vmlinux indeed, but it doesn't help
2013-09-18 09:55 <viric> but your vmlinux needs debug info.
2013-09-18 09:57 <apelete> viric: forgot to mention it, I also have:
2013-09-18 09:57 <apelete> CONFIG_DEBUG_INFO=y
2013-09-18 09:57 <apelete> CONFIG_DEBUG_KERNEL=y
2013-09-18 09:57 <apelete> I really don't see what I'm missing :-(
2013-09-18 09:57 <viric> does gdb attach fine?
2013-09-18 09:57 <apelete> yes
2013-09-18 09:57 <viric> Are you using a mips gdb? :)
2013-09-18 09:58 <apelete> ha...
2013-09-18 09:58 <apelete> no.
2013-09-18 09:58 <viric> here it is :)
2013-09-18 09:59 <apelete> viric: I'm using my debian flavoured x86 gdb. how can I get a mips gdb ?
2013-09-18 09:59 <viric> ask your toolchain provider
2013-09-18 10:00 <viric> those who gave you a gcc for mips, should be able to give you a gdb for mips
2013-09-18 10:00 <apelete> that's the Qi Hw guys :-). will a take a look at the nanonote wiki then
2013-09-18 10:02 <apelete> viric: I always forget about the toolchain, been used to debug x86 hardware I guess. thanks for the tip, will let you know if it works
2013-09-18 10:03 <whitequark> [insert a rant about the unnecessity of target-specific toolchains]
2013-09-18 10:07 <apelete> whitequark: how can target-specific toolchains be unnecessary since we already need them ? :-)
2013-09-18 10:08 <whitequark> apelete: other toolchains *cough*LLVM+LLDB*cough* don't need to be recompiled for each target.
2013-09-18 10:09 <apelete> whitequark: wow, are you serious ? didn't know it was even possible oO
2013-09-18 10:09 rz2k has quit []
2013-09-18 10:10 <whitequark> it is trivial, if you don't abuse macros and global variables and so on
2013-09-18 10:10 <apelete> never used anyhting else than gcc+gdb, I didn't know LLVM+LLDB had such an advantage
2013-09-18 10:10 <apelete> s/anyhting/anything/
2013-09-18 10:10 <qi-bot> apelete meant: "never used anything else than gcc+gdb, I didn't know LLVM+LLDB had such an advantage"
2013-09-18 10:10 <roh> llvm and lldb do not support that much platforms at all, so there is no point
2013-09-18 10:11 <whitequark> well. LLVM is a mature compiler. LLD (its linker) is definitely not production-quality. LLDB is halfway: it's the default OS X debugger, but it severely lacks support for targets interesting to us
2013-09-18 10:12 * whitequark is still using gdb
2013-09-18 10:12 <whitequark> roh: llvm supports all major platforms well though
2013-09-18 10:12 <whitequark> x86, arm, various mipses
2013-09-18 10:13 <roh> whitequark: well.. cross?
2013-09-18 10:13 * apelete should read more about toolchains and compilers...
2013-09-18 10:13 <whitequark> roh: hm?
2013-09-18 10:14 <roh> whitequark: last time i watched somebody try using llvm to compile stuff for arm it was like 2 days before he gave up
2013-09-18 10:14 <whitequark> llvm has no notion of cross-compiling, you just select the triple and options and that's it
2013-09-18 10:15 <whitequark> not sure when was that. it's incredibly easy, both in clang and for your own frontend
2013-09-18 10:15 rz2k has joined #qi-hardware
2013-09-18 10:15 jekhor has quit [Ping timeout: 256 seconds]
2013-09-18 10:15 <roh> whitequark: the result was, it compiled broken binaries on x86, different ones when run on amd64, and only correct ones run on arm. the cross part was badly broken
2013-09-18 10:16 <roh> about ~1year ago in winter
2013-09-18 10:16 <roh> the target was some lpc something arm7/cortex m0 mcu
2013-09-18 10:16 <roh> ah.. and yes.. all the mcu targets are missing anyhow
2013-09-18 10:17 <whitequark> roh: I can just say that 3.2/3.3/3.4 which I use together with my compiler generate working code for x86/arm with no problems
2013-09-18 10:17 <whitequark> I can't elaborate on his problem without further details
2013-09-18 10:17 <roh> whitequark: ever tried non-linux targets?
2013-09-18 10:17 <whitequark> sure, my main target is baremetal cortex-m3
2013-09-18 10:17 <roh> nice to hear that works finally
2013-09-18 10:18 <roh> to be fair, i stopped even looking at llvm when i learned about how half-done it was.
2013-09-18 10:18 <whitequark> clang "almost" compiles kernel on x86/arm, "almost" meaning there is less than a dozen of patches which kill various horrible gcc extensions pending merge
2013-09-18 10:18 <roh> i know compilerbugs from gcc well, but usually you need to do ugly shit to provoke them
2013-09-18 10:19 <roh> well.. most gcc extensions used in the kernel make lots of sense to me. i woulnt know any other way to write it down less ugly
2013-09-18 10:19 <whitequark> roh: you may want to revise that. clang+llvm are very good (on par with gcc) on major targets in my experience. lld/lldb are indeed half-done, though that changes.
2013-09-18 10:20 <whitequark> (gcc extensions) it's not most of them which cause problems, but a few really horrible ones
2013-09-18 10:20 <roh> whitequark: i use not only major targets. is there avr already?
2013-09-18 10:20 <whitequark> no
2013-09-18 10:21 <whitequark> until recently there wasn't good multiple address space support. from 3.4 onwards it's simple
2013-09-18 10:22 <roh> i see.. well.. maybe i should revisit it.
2013-09-18 10:22 <whitequark> imo the main advantage of llvm is that it has very simple and clean architecture (not just compared to gcc). it's both easy to write *a* codegen, and a *good* codegen
2013-09-18 10:22 <roh> given that somebody finds nicer replacement for gcc extentsions
2013-09-18 10:22 <apelete> viric: found it:
2013-09-18 10:22 <apelete> $ find ~/devel/qi-tools/toolchain/ -name "*gdb*"
2013-09-18 10:22 <apelete> /home/apelete/devel/qi-tools/toolchain/lib/libstdc++.so.6.0.16-gdb.py
2013-09-18 10:22 <apelete> /home/apelete/devel/qi-tools/toolchain/bin/mipsel-openwrt-linux-gdb
2013-09-18 10:22 <apelete> /home/apelete/devel/qi-tools/toolchain/bin/mipsel-openwrt-linux-uclibc-gdb
2013-09-18 10:23 <apelete> will try it tonight, when I get back from work :-)
2013-09-18 10:23 <roh> writing everything in k&R c would not only be madness, it would look ugly, and make code completely unmaintainable.. which for sure is not the goal
2013-09-18 10:23 <whitequark> roh: it supports vast majority of gcc extensions, even gcc inline assembly
2013-09-18 10:23 <roh> ah. thats one way of 'solving' this.. i hoped for something less ... gcc-esque ;)
2013-09-18 10:23 <whitequark> the ones which won't work are target-specific ones which do not map at all to LLVM architecure, say pinning variables to registers
2013-09-18 10:24 <whitequark> well it has to be compatible with existing code... who wants n+1 standards?
2013-09-18 10:25 <whitequark> see also http://clang.debian.net/
2013-09-18 10:25 <wpwrak> gcc is a pretty good base when it comes to extensions. they may not always look great, but then look at what the competition is doing ...
2013-09-18 10:25 <roh> well.. i guess when openwrt adds clang as optional compiler that would get people to nod and acknowledge
2013-09-18 10:26 <whitequark> roh: I think freebsd switched to clang already
2013-09-18 10:26 <roh> wpwrak: ack. especially give the shitloads of platforms
2013-09-18 10:26 <whitequark> wpwrak: agreed, gcc has a lot of useful stuff
2013-09-18 10:26 <roh> whitequark: fbsd has a extremely small codebase compared to linux
2013-09-18 10:26 <roh> whitequark: 99% of linux are drivers
2013-09-18 10:26 <roh> >80% of those arent for x86 compat.
2013-09-18 10:26 <whitequark> roh: for those see http://llvm.linuxfoundation.org/
2013-09-18 10:28 <roh> whitequark: thats only for platforms linux works on, which is a multiple of fbsd. there are much more devices out there. to small for linux, but not for widespread use.
2013-09-18 10:28 <roh> bigger than werners 8051 ;)
2013-09-18 10:29 <whitequark> sure
2013-09-18 10:29 <whitequark> but that's at least a solid metric instead of vague promises :)
2013-09-18 10:29 <roh> my point being.. everybody kicks on gcc.. but yet it is still not replaceable. only SOME of its uses are
2013-09-18 10:30 <roh> still gcc has helped us all a lot in the last 2 decades
2013-09-18 10:30 <whitequark> true
2013-09-18 10:32 <wpwrak> more like 2.5 if not more :)
2013-09-18 10:33 <wpwrak> anybody remembers when the big commercial unices started to "unbundle" compilers ? that was when gcc really rose to power
2013-09-18 10:33 <roh> yup. so i guess from my personal pov there would be 2 milestones. one would be openwrt adding it as a second compiler, one would be working avr support.
2013-09-18 10:34 <roh> but as long as that doesnt happen (openwrt needs mips working properly) i guess i will stay true to my gcc for now ;)
2013-09-18 10:34 <wpwrak> plan B: sneak into atmel HQ, delete all the AVR files, burn the backups, then see how long it takes them to switch to ARM :) (it may be more of a challenge for marketing than for the engineers)
2013-09-18 10:35 <roh> wpwrak: arm sucks at the scales they build cpus
2013-09-18 10:35 <whitequark> roh: there's a lot of mips activity in llvm judging by ML (I don't build mips things though)
2013-09-18 10:35 <wpwrak> in what sense ?
2013-09-18 10:35 <roh> wpwrak: with an arm you cannot wiggle a gpio at 1/2 of the cpuclock.
2013-09-18 10:35 <wpwrak> weeeellll...
2013-09-18 10:36 <whitequark> roh: you can on some chips :)
2013-09-18 10:36 <roh> wpwrak: smaller cores, simpler design than arm, much less levels of bus shit etc.
2013-09-18 10:36 <wpwrak> i'm not even sure this is true. e.g., look at freescale's FGPIO
2013-09-18 10:36 <roh> last time i checked all arms i looked at, had a bus between gpio and core.
2013-09-18 10:36 <wpwrak> and then, atmel crawls at something like 8 MHz in an environment in which an ARM happily does at least four times that speed.
2013-09-18 10:36 <roh> if its ahb or whatever doesnt matter. too slow.
2013-09-18 10:37 <whitequark> do you need to bitbang things at >50mhz?
2013-09-18 10:37 <roh> wpwrak: bullshit.. 8mhz is slow for these.. the avr32 go up to high 2 digit numbers by default and the small old ones to 20 or 25
2013-09-18 10:38 <whitequark> because 50mhz is the fastest gpio hw can go, and I'm pretty sure stm32f1 can do that, but I can verify for you if you want
2013-09-18 10:38 <wpwrak> see page 101 on http://cache.freescale.com/files/32bit/doc/ref_manual/KL25P80M48SF0RM.pdf
2013-09-18 10:38 <roh> whitequark: usually not. but everybody who needed to speak onewire (the ti crap) withz an arm once and with an avr, knows that its MUCH easier and less work to get the timing jitterless on an avr
2013-09-18 10:38 <wpwrak> "The GPIO is multi-ported and can be accessed directly by the core with zero wait states"
2013-09-18 10:39 <wpwrak> not sure how many cycles this means in the end, but it ought to be fast
2013-09-18 10:39 <roh> sbi is one cycle. thats why avr is nice. nearly all instructions are one cycle
2013-09-18 10:39 <wpwrak> roh: (avr, fast) 20 MHz ... at 5 V :)
2013-09-18 10:40 <wpwrak> whitequark: stm32 is way too powerful for that comparison ;-)
2013-09-18 10:40 <whitequark> roh: I see, it's true that jitter will be harder to remove
2013-09-18 10:40 rz2k has quit []
2013-09-18 10:40 <wpwrak> but try the freescale kinetis series. they seem pretty decent, though somewhat overlooked
2013-09-18 10:40 <roh> wpwrak: if you need faster, maybe you chose the wrong cpu. i use them a lot for controlling work, where arm or so would be much more work to get the soc running. sleeping most of the time.. doing complex triggers etc.
2013-09-18 10:41 <wpwrak> and they're actually cheaper than avrs ;-)
2013-09-18 10:41 <roh> wpwrak: maybe. but 1$ difference doesnt matter if i get the work done in half the time
2013-09-18 10:41 <whitequark> roh: not sure what you need to "get the soc running". stm32f1s require literally zero initialization
2013-09-18 10:41 <roh> there is a reason for arduino using avr for most of their platforms
2013-09-18 10:42 <roh> whitequark: external hardware, bootcode
2013-09-18 10:42 <whitequark> one line of it to enable gpios. another two lines to switch to crystal. it's actually harder to muck with the option bytes on avr
2013-09-18 10:42 <wpwrak> yes, getting an arm running is a bit of a hassle. what's basically missing is the equivalent of avr-libc. i have high hopes for libopencm3, maybe with newlib, in that regard.
2013-09-18 10:42 <whitequark> wpwrak: cmsis?
2013-09-18 10:42 <whitequark> roh: which external hardware? avrs and arms need a bypass cap and an oscillator
2013-09-18 10:43 <wpwrak> whitequark: good luck with the on-chip peripherals :)
2013-09-18 10:43 <whitequark> which bootcode? avrs require a programmer, cortexes have swd, which is essentially same thing
2013-09-18 10:43 <roh> whitequark: not neccessarily. there is a 8mhz rc inside and also a pll if needed
2013-09-18 10:43 <whitequark> roh: on both of them
2013-09-18 10:43 <wpwrak> of course, you can use stm's peripheral lib ...
2013-09-18 10:43 <whitequark> wpwrak: imo all vendor libs suck, hw companies shouldn't ever attempt to write software
2013-09-18 10:44 <roh> ive used stm32 recently. nice for an arm, but way more complicated
2013-09-18 10:44 <wpwrak> that seems to be good advice :)
2013-09-18 10:44 <roh> whitequark: ack.
2013-09-18 10:44 Jay7x has quit [Ping timeout: 248 seconds]
2013-09-18 10:44 <roh> about the "hw companies shouldn't ever attempt to write software"
2013-09-18 10:44 <roh> thats even true for intel and co.
2013-09-18 10:45 <whitequark> ACPI+EFI
2013-09-18 10:45 * whitequark shudders
2013-09-18 10:45 <roh> whitequark: not even that. check out your network drivers
2013-09-18 10:45 <whitequark> roh: wired or wireless?
2013-09-18 10:46 <roh> both
2013-09-18 10:46 <whitequark> iwlwifi is pretty horrible indeed. still better than broadcom though
2013-09-18 10:46 <roh> e1000 and iwlwifi both already had bad bugs
2013-09-18 10:46 <roh> in hw as in sw
2013-09-18 10:46 <whitequark> it has power management disabled by default
2013-09-18 10:46 <whitequark> which is telling
2013-09-18 10:46 <roh> acpi and efi are a multi-vendor-crime
2013-09-18 10:47 <whitequark> also it only works well for me with swcrypto=1 which is also telling
2013-09-18 10:47 <whitequark> (efi) before efi, i thought bios was bad. nope, it actually was an excellent, well-designed and thought out piece of software
2013-09-18 10:48 <roh> *g*
2013-09-18 10:49 <whitequark> a guy i know bricked an efi intel board and recovered it in an email conversation with intel
2013-09-18 10:49 <wpwrak> and then they hired beavis and butthead ... "let's break something"
2013-09-18 10:49 <whitequark> when he explained how he did it they offered to hire him
2013-09-18 10:49 <wpwrak> ;-))
2013-09-18 10:50 <whitequark> perhaps efi is just a very contrived way to interview candidates
2013-09-18 10:50 <roh> ever went to school? thats not where engineers come from!
2013-09-18 10:50 <whitequark> roh: I could be a bioengineer
2013-09-18 10:50 <roh> i guess its just statistical errors now (having engineers) and when you find one, you try to hire em.
2013-09-18 10:50 <wpwrak> reminds me of the old joke about programming languages. (obfuscated) C programmer proudly shows his program to colleagues and asks "can you tell what it does ?". APL programmer shows his program and asks "can you PLEASE tell me what it does ?"
2013-09-18 10:51 <whitequark> wpwrak: hahaha
2013-09-18 10:51 <larsc> :)
2013-09-18 10:51 <roh> hrr
2013-09-18 10:51 <whitequark> roh: good for employment!
2013-09-18 10:53 * larsc develops software for a hardware company :/
2013-09-18 10:53 <roh> larsc: as a freelancer?
2013-09-18 10:53 <larsc> as a employee
2013-09-18 10:53 <roh> i think its only getting dangerous as long term employee
2013-09-18 10:54 <larsc> almost two years now
2013-09-18 10:54 <roh> since that makes you (usually) blind to the developments of the direct competition, their solutions etc... but knowing you are a hacker i guess not even your boss could hinder you reading also different datasheets
2013-09-18 10:55 <whitequark> roh: wait, why would anyone *want* to hinder people on that?
2013-09-18 10:55 <roh> e.g. on the intel, amd, nvidia stuff.. you see they have basically the same solutions to complex problems on their cpus, and all name it differently, have different parameter settings on these features etc.. but in the end... it doesnt matter how you call it.
2013-09-18 10:56 <roh> whitequark: intel seems to do that. atleast i know of no other way to write that stupid code.
2013-09-18 10:57 <roh> also it makes designing new subsystems pain, when you have no clue what your other developerfriends would need to have for an interface for the competitions hardware
2013-09-18 10:57 <larsc> I don't think not reading datasheets for other devices correlates to writing bad code
2013-09-18 10:57 <roh> larsc: it does because it makes you not see different designs and hardware layouts. you only see THE company flavour. that is what makes bad designs. blindness by too much of the same
2013-09-18 10:58 <roh> you know the sentence 'den wald vor lauter baeumen nicht sehn'?
2013-09-18 11:00 <whitequark> offtopic: it's an exactly same idiom in russian (and apparently english)
2013-09-18 11:00 <roh> funky
2013-09-18 11:01 <larsc> now we are talking about bad design
2013-09-18 11:02 <larsc> you can still write good code for a bad design
2013-09-18 11:02 <larsc> it's different layers
2013-09-18 11:02 <whitequark> most code by hw vendors I've seen was written like an afterthought
2013-09-18 11:03 <whitequark> "yeah, and now let's cobble some procedures together to configure our perfect core"
2013-09-18 11:03 <whitequark> said to a first-year intern
2013-09-18 11:03 dos1 has joined #qi-hardware
2013-09-18 11:04 <roh> larsc: i'd rather have code written by somebody with access to documentation and hardware, than by somebody within the vendor who writes only drivers for that one vendors from time to time.
2013-09-18 11:05 <roh> usually it ends up with 'the guy who gets documentation access has written 10 drivers for 5 vendors and knows his framework'
2013-09-18 11:05 <roh> compared to 'the guy from the vendor is learning how to write his first kerneldriver ever from a book now'
2013-09-18 11:06 <roh> sure. there are good and bad examples for both ends of the spectrum. there is what ive seen live to often
2013-09-18 11:06 <larsc> If only people who already have already written 10 drivers get to write drivers, you'll never get new people to write drivers
2013-09-18 11:07 <whitequark> you probably shouldn't ship drivers written by complete novices without any modification though
2013-09-18 11:07 <larsc> 'proper code review' is the catchphrase here
2013-09-18 11:07 <roh> larsc: true. but i guess you know what i mean. the 10 drivery already guy is a freelancer or short time employee on project basis
2013-09-18 11:08 <roh> the in-house coder is very often a student of some it foo and then gets to do that because he was ne only one not in holiday when they searched for a c-coder inhouse
2013-09-18 11:09 <roh> same is true for non-linux platform drivers as well.. i can show you a few examples when we meet at some point (win32 driver sources
2013-09-18 11:09 <larsc> I'm not even sure I want to see that ;)
2013-09-18 11:09 <roh> code review. nice idea. never seen that at a hw vendor.(yet)
2013-09-18 11:10 <roh> larsc: hrhr. true
2013-09-18 11:10 <larsc> we do code review
2013-09-18 11:10 <larsc> or well I do code review
2013-09-18 11:10 <larsc> ;)
2013-09-18 11:11 <roh> hehe.. where you working at?
2013-09-18 11:11 <larsc> Analog Devices
2013-09-18 11:11 <roh> nice. also i must say, i havent heard anything bad.. which is a good sign in that business i guess
2013-09-18 11:12 <roh> can you tell what kind of devices you usually write drivers for there?
2013-09-18 11:13 <larsc> http://wiki.analog.com/resources/tools-software/linux-drivers-all
2013-09-18 11:14 <roh> wow. long list
2013-09-18 11:15 <larsc> and due to good design we are able to reuse the same driver for multiple devices
2013-09-18 11:17 <roh> i guess thats where you differ to the typical inhouse coder already. they seem not even to care for something like that (code reuse)
2013-09-18 11:20 <larsc> I'm makeing myself obsolete (like any good engineer ;) )
2013-09-18 11:23 <roh> :)
2013-09-18 11:29 <wpwrak> (driver reuse) gcc -DADP8861 -c lars.c
2013-09-18 11:30 <wpwrak> roh: oh, but they do. they take the vendor package, make a copy, and use it to death. then the product ships and they never touch the code again.
2013-09-18 11:32 FDCX_ has quit [Ping timeout: 264 seconds]
2013-09-18 11:34 <roh> wpwrak: exactly. thus it never gets reviewd, debugged, fixed, or security-patched
2013-09-18 11:40 xiangfu has quit [Ping timeout: 264 seconds]
2013-09-18 11:40 pcercuei has joined #qi-hardware
2013-09-18 11:53 <whitequark> I really wish LLVM compiled faster
2013-09-18 11:53 * whitequark probably spends half of his time compiling LLVM these days
2013-09-18 11:54 <larsc> are you compiling with gcc or with llvm? ;)
2013-09-18 11:55 <whitequark> depends
2013-09-18 11:55 <whitequark> the debian package prefers gcc
2013-09-18 11:56 <whitequark> though by now, the time spent compiling it would probably be bigger than time required to figure out how to adjust the package
2013-09-18 11:56 <pcercuei> compiling mipsel-linux-llvm? :)
2013-09-18 11:56 <whitequark> pcercuei: arm-none
2013-09-18 11:57 <whitequark> well, there's no such thing as cross-llvm, but I use it for arm-none-eabi.
2013-09-18 12:13 xiangfu has joined #qi-hardware
2013-09-18 12:42 Jay7 has joined #qi-hardware
2013-09-18 12:52 jekhor has joined #qi-hardware
2013-09-18 13:37 <cde> roh: what does hrhr mean?
2013-09-18 13:45 <larsc> http://www.urbandictionary.com/define.php?term=hrhr
2013-09-18 13:45 <larsc> not 1)
2013-09-18 13:47 <wpwrak> naw. it's the shortened professional form of ballmer's "developers ! developers !". it's "human resources ! human resources !"
2013-09-18 13:50 <ysionneau> http://mailman.cs.huji.ac.il/pipermail/linux-il/2013-September/010649.html :o
2013-09-18 13:54 <larsc> so basically userspace in ring1
2013-09-18 13:54 <larsc> but makes sense
2013-09-18 14:02 <wpwrak> "Another refreshing feature of OSv is that is written in C++." how boring. why not C#, Go, don't apple have any hip new language ? and where's Cloud-Ready Parallel Object-COBOL when we need it ?
2013-09-18 14:03 <wpwrak> though things seem to be moving at breakneck speed in the COBOL world. last thing i heard, they relaxed the format of the punch cards. a daring move for sure.
2013-09-18 14:04 <larsc> why not javascript?
2013-09-18 14:05 <wpwrak> isn't that, like, very 2012 ?
2013-09-18 14:05 dos1 has quit [Quit: Kabum!]
2013-09-18 14:06 <larsc> so a robust technology
2013-09-18 14:07 dos1 has joined #qi-hardware
2013-09-18 14:11 <whitequark> larsc: https://github.com/charliesome/jsos/
2013-09-18 14:11 <mth> C++11 feels like a new language
2013-09-18 14:13 <whitequark> wpwrak: http://www.netcobol.com/
2013-09-18 14:13 <whitequark> ... which is precisely, down to every word, what you asked for. :D
2013-09-18 14:13 <Freemor> wpwrak: I still have nightmares of bubbling in: 02 filler pic ...
2013-09-18 14:16 <Freemor> and waiting in terrified anticipation for the card reader to mangle and jam on sone card in the middle of the deck
2013-09-18 14:16 xiangfu has quit [Ping timeout: 264 seconds]
2013-09-18 14:17 <wpwrak> too cool ;-) reality mimicking and even mocking sarcasm :)
2013-09-18 14:17 <Freemor> lol
2013-09-18 14:19 <whitequark> larsc: though charliesome is generally a good fellow, that's a joke project
2013-09-18 14:19 <wpwrak> (netcobol) "modernize your indexed file systems". why do i have the mental image of a stone age businessman shouting this into a cave ?
2013-09-18 14:20 <whitequark> lol
2013-09-18 14:20 * Freemor feels old
2013-09-18 14:23 xiangfu has joined #qi-hardware
2013-09-18 14:23 <Freemor> but then 48 is like 100K in computer years
2013-09-18 14:27 <viric> Freemor: you must be one of those who invented the computers
2013-09-18 14:27 <viric> :)
2013-09-18 14:31 * whitequark . o O ( EWD )
2013-09-18 14:32 <wpwrak> hmm, a ~1965 model. that would be about 1 petacycle at the computer technology of that time
2013-09-18 14:42 <Freemor> no, no, just got started on them bac when they ran on wood, 300 baud ruled (with 110 baud as a fall back for dirty lines), and things lije zip, gif, jpg, etc weren't invented yet.
2013-09-18 14:43 <wpwrak> who needs ZIP if you have ARC ?
2013-09-18 14:43 <Freemor> lol
2013-09-18 14:44 <wpwrak> and who needs TCP/IP if you have kermit and xmodem ? well, things got *really* fancy, when "term" appeared. more than one data stream over the same (!) line
2013-09-18 14:45 <Freemor> i miss xmodem (in that naustalgic don't really remember how bad it was kinda way)
2013-09-18 14:47 <Freemor> before that all we had was the equivelent of cat foo > /dev/ TTyS0 and pray
2013-09-18 14:48 <viric> I remember the choice xmodem, ymodem, zmodem.
2013-09-18 14:48 <viric> was zmodem the best?
2013-09-18 14:48 <Freemor> yep
2013-09-18 14:49 <Freemor> had things like resuming a failed transfer and better thru put
2013-09-18 14:49 <viric> I remember I was reverse engineering the cool interlnk.exe/intersvr.exe, to implement a linux side
2013-09-18 14:50 <viric> Freemor: I remember zmodem resisting errors
2013-09-18 14:51 <Freemor> yep
2013-09-18 14:51 <Freemor> zmodem was nice
2013-09-18 14:52 * Freemor still has a 56k v42bis full hardware modem around
2013-09-18 14:54 <Freemor> no acoustic coupler tho :)
2013-09-18 15:29 lekernel_ has joined #qi-hardware
2013-09-18 15:30 lekernel has quit [Read error: Connection reset by peer]
2013-09-18 15:41 FDCX_ has joined #qi-hardware
2013-09-18 15:42 jekhor has quit [Ping timeout: 264 seconds]
2013-09-18 15:50 wej has quit [Ping timeout: 245 seconds]
2013-09-18 16:00 dos1 has quit [Quit: Kabum!]
2013-09-18 16:01 dos1 has joined #qi-hardware
2013-09-18 16:08 dos1 has quit [Read error: Connection reset by peer]
2013-09-18 16:08 dos11 has joined #qi-hardware
2013-09-18 16:10 dos11 has quit [Read error: Connection reset by peer]
2013-09-18 16:10 dos1 has joined #qi-hardware
2013-09-18 16:16 dos1 has quit [Read error: Connection reset by peer]
2013-09-18 16:16 dos1 has joined #qi-hardware
2013-09-18 16:54 xiangfu has quit [Remote host closed the connection]
2013-09-18 17:16 dos11 has joined #qi-hardware
2013-09-18 17:16 dos1 has quit [Ping timeout: 276 seconds]
2013-09-18 17:23 <whitequark> I know a guy who still uses zmodem
2013-09-18 17:24 <whitequark> zmodem is at least two times older than him
2013-09-18 17:26 WielkiTost has joined #qi-hardware
2013-09-18 17:27 dos11 has quit [Ping timeout: 248 seconds]
2013-09-18 17:29 WielkiTost is now known as dos1
2013-09-18 17:54 <viric> whitequark: retro trend
2013-09-18 17:55 <whitequark> viric: he wanted to upload firmware to an fpga via uart or something
2013-09-18 17:57 <viric> :)
2013-09-18 18:14 rz2k has joined #qi-hardware
2013-09-18 18:23 <whitequark> argh, I just bricked a completely new jlink clone
2013-09-18 18:27 <cde> how?
2013-09-18 18:27 <viric> with ruby?
2013-09-18 18:28 <whitequark> turned it on and ran segger's gdbserver
2013-09-18 18:28 <whitequark> it attempted to automatically update the firmware. that NEVER works.
2013-09-18 18:28 <cde> you gdbserver tries to update the firmware? wierd
2013-09-18 18:29 <whitequark> that's how jlink tools work
2013-09-18 19:04 rz2k has quit [Read error: Connection reset by peer]
2013-09-18 19:04 rz2k has joined #qi-hardware
2013-09-18 19:45 rz2k has quit [Read error: Connection reset by peer]
2013-09-18 19:46 rz2k has joined #qi-hardware
2013-09-18 20:14 jekhor has joined #qi-hardware
2013-09-18 20:25 <apelete> viric: you were right about this morning, using the gdb coming from the toolchain and built for mips target solved it
2013-09-18 20:26 <apelete> here is a gdb session with the debian x86 gdb: http://paste.debian.net/42536/
2013-09-18 20:28 <apelete> now debugging same executable with gdb for mips target: http://paste.debian.net/42540/
2013-09-18 20:33 <apelete> viric: I can start debugging properly now, thanks again for the help
2013-09-18 20:36 <viric> nice
2013-09-18 20:36 <viric> you are welcome
2013-09-18 20:53 pcercuei has quit [Read error: Connection reset by peer]
2013-09-18 21:03 pcercuei has joined #qi-hardware
2013-09-18 21:04 rz2k has quit []
2013-09-18 21:52 jekhor has quit [Ping timeout: 240 seconds]
2013-09-18 21:57 lekernel_ has quit [Quit: Leaving]
2013-09-18 22:00 Jay7 has quit [Ping timeout: 248 seconds]
2013-09-18 22:04 <DocScrutinizer05> http://bellard.org/dvbt/  :-D
2013-09-18 22:12 wolfspraul has quit [Quit: leaving]
2013-09-18 22:18 <apelete> adding kgdbcon to boot params works well too: http://paste.debian.net/42597/
2013-09-18 22:19 <DocScrutinizer05> whitequark: zmodem still is standard for a lot of things, like transfer of firmware images to flash devices
2013-09-18 23:07 dos1 has quit [Quit: Kabum!]
2013-09-18 23:07 dos1 has joined #qi-hardware
2013-09-18 23:08 dos1 has quit [Client Quit]
2013-09-18 23:31 Jay7 has joined #qi-hardware
2013-09-18 23:38 dos1 has joined #qi-hardware