#qi-hardware IRC log for Wednesday, 2013-09-18

apeletehas anyuone here tried to debug the Nanonote kernel with kgdb ?09:46
viricapelete: http://viric.name/cgi-bin/nanonixos/doc/trunk/doc/kerneldbg/index.wiki09:50
apeleteI built 3.9 with the following debug options for kgdb:09:52
apelete# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set09:52
apeletebut the gdb backtrace output is almost empty, preventing me to debug anything09:53
apeleteviric: you seem to get a correct gdb behaviour, any idea about what I am missing ?09:54
viricyou need a vmlnux with debug info09:54
viricthere is a CONFIG_DEBUG or so09:55
apeleteviric: I flashed the uImage to NN and launched gdb with vmlinux indeed, but it doesn't help09:55
viricbut your vmlinux needs debug info.09:55
apeleteviric: forgot to mention it, I also have:09:57
apeleteI really don't see what I'm missing :-(09:57
viricdoes gdb attach fine?09:57
viricAre you using a mips gdb? :)09:57
virichere it is :)09:58
apeleteviric: I'm using my debian flavoured x86 gdb. how can I get a mips gdb ?09:59
viricask your toolchain provider09:59
viricthose who gave you a gcc for mips, should be able to give you a gdb for mips10:00
apeletethat's the Qi Hw guys :-). will a take a look at the nanonote wiki then10:00
apeleteviric: I always forget about the toolchain, been used to debug x86 hardware I guess. thanks for the tip, will let you know if it works10:02
whitequark[insert a rant about the unnecessity of target-specific toolchains]10:03
apeletewhitequark: how can target-specific toolchains be unnecessary since we already need them ? :-)10:07
whitequarkapelete: other toolchains *cough*LLVM+LLDB*cough* don't need to be recompiled for each target.10:08
apeletewhitequark: wow, are you serious ? didn't know it was even possible oO10:09
whitequarkit is trivial, if you don't abuse macros and global variables and so on10:10
apeletenever used anyhting else than gcc+gdb, I didn't know LLVM+LLDB had such an advantage10:10
rohllvm and lldb do not support that much platforms at all, so there is no point10:10
whitequarkwell. 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 us10:11
Action: whitequark is still using gdb10:12
whitequarkroh: llvm supports all major platforms well though10:12
whitequarkx86, arm, various mipses10:12
rohwhitequark: well.. cross?10:13
Action: apelete should read more about toolchains and compilers...10:13
whitequarkroh: hm?10:13
rohwhitequark: last time i watched somebody try using llvm to compile stuff for arm it was like 2 days before he gave up10:14
whitequarkllvm has no notion of cross-compiling, you just select the triple and options and that's it10:14
whitequarknot sure when was that. it's incredibly easy, both in clang and for your own frontend10:15
rohwhitequark: 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 broken10:15
rohabout ~1year ago in winter10:16
rohthe target was some lpc something arm7/cortex m0 mcu10:16
rohah.. and yes.. all the mcu targets are missing anyhow10:16
whitequarkroh: 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 problems10:17
whitequarkI can't elaborate on his problem without further details10:17
rohwhitequark: ever tried non-linux targets?10:17
whitequarksure, my main target is baremetal cortex-m310:17
rohnice to hear that works finally10:17
rohto be fair, i stopped even looking at llvm when i learned about how half-done it was.10:18
whitequarkclang "almost" compiles kernel on x86/arm, "almost" meaning there is less than a dozen of patches which kill various horrible gcc extensions pending merge10:18
rohi know compilerbugs from gcc well, but usually you need to do ugly shit to provoke them10:18
rohwell.. most gcc extensions used in the kernel make lots of sense to me. i woulnt know any other way to write it down less ugly10:19
whitequarkroh: 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.10:19
whitequark(gcc extensions) it's not most of them which cause problems, but a few really horrible ones10:20
rohwhitequark: i use not only major targets. is there avr already?10:20
whitequarkuntil recently there wasn't good multiple address space support. from 3.4 onwards it's simple10:21
rohi see.. well.. maybe i should revisit it.10:22
whitequarkimo 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* codegen10:22
rohgiven that somebody finds nicer replacement for gcc extentsions10:22
apeleteviric: found it:10:22
apelete$ find ~/devel/qi-tools/toolchain/ -name "*gdb*"10:22
apeletewill try it tonight, when I get back from work :-)10:23
rohwriting 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 goal10:23
whitequarkroh: it supports vast majority of gcc extensions, even gcc inline assembly10:23
rohah. thats one way of 'solving' this.. i hoped for something less ... gcc-esque ;)10:23
whitequarkthe ones which won't work are target-specific ones which do not map at all to LLVM architecure, say pinning variables to registers10:23
whitequarkwell it has to be compatible with existing code... who wants n+1 standards?10:24
whitequarksee also http://clang.debian.net/10:25
wpwrakgcc 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 ...10:25
rohwell.. i guess when openwrt adds clang as optional compiler that would get people to nod and acknowledge10:25
whitequarkroh: I think freebsd switched to clang already10:26
rohwpwrak: ack. especially give the shitloads of platforms10:26
whitequarkwpwrak: agreed, gcc has a lot of useful stuff10:26
rohwhitequark: fbsd has a extremely small codebase compared to linux10:26
rohwhitequark: 99% of linux are drivers10:26
roh>80% of those arent for x86 compat.10:26
whitequarkroh: for those see http://llvm.linuxfoundation.org/10:26
rohwhitequark: 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.10:28
rohbigger than werners 8051 ;)10:28
whitequarkbut that's at least a solid metric instead of vague promises :)10:29
rohmy point being.. everybody kicks on gcc.. but yet it is still not replaceable. only SOME of its uses are10:29
rohstill gcc has helped us all a lot in the last 2 decades10:30
wpwrakmore like 2.5 if not more :)10:32
wpwrakanybody remembers when the big commercial unices started to "unbundle" compilers ? that was when gcc really rose to power10:33
rohyup. 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.10:33
rohbut as long as that doesnt happen (openwrt needs mips working properly) i guess i will stay true to my gcc for now ;)10:34
wpwrakplan 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)10:34
rohwpwrak: arm sucks at the scales they build cpus10:35
whitequarkroh: there's a lot of mips activity in llvm judging by ML (I don't build mips things though)10:35
wpwrakin what sense ?10:35
rohwpwrak: with an arm you cannot wiggle a gpio at 1/2 of the cpuclock.10:35
whitequarkroh: you can on some chips :)10:36
rohwpwrak: smaller cores, simpler design than arm, much less levels of bus shit etc.10:36
wpwraki'm not even sure this is true. e.g., look at freescale's FGPIO10:36
rohlast time i checked all arms i looked at, had a bus between gpio and core.10:36
wpwrakand then, atmel crawls at something like 8 MHz in an environment in which an ARM happily does at least four times that speed.10:36
rohif its ahb or whatever doesnt matter. too slow.10:36
whitequarkdo you need to bitbang things at >50mhz?10:37
rohwpwrak: 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 2510:37
whitequarkbecause 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 want10:38
wpwraksee page 101 on http://cache.freescale.com/files/32bit/doc/ref_manual/KL25P80M48SF0RM.pdf10:38
rohwhitequark: 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 avr10:38
wpwrak"The GPIO is multi-ported and can be accessed directly by the core with zero wait states"10:38
wpwraknot sure how many cycles this means in the end, but it ought to be fast10:39
rohsbi is one cycle. thats why avr is nice. nearly all instructions are one cycle10:39
wpwrakroh: (avr, fast) 20 MHz ... at 5 V :)10:39
wpwrakwhitequark: stm32 is way too powerful for that comparison ;-)10:40
whitequarkroh: I see, it's true that jitter will be harder to remove10:40
wpwrakbut try the freescale kinetis series. they seem pretty decent, though somewhat overlooked10:40
rohwpwrak: 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.10:40
wpwrakand they're actually cheaper than avrs ;-)10:41
rohwpwrak: maybe. but 1$ difference doesnt matter if i get the work done in half the time10:41
whitequarkroh: not sure what you need to "get the soc running". stm32f1s require literally zero initialization10:41
rohthere is a reason for arduino using avr for most of their platforms10:41
rohwhitequark: external hardware, bootcode10:42
whitequarkone line of it to enable gpios. another two lines to switch to crystal. it's actually harder to muck with the option bytes on avr10:42
wpwrakyes, 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. 10:42
whitequarkwpwrak: cmsis?10:42
whitequarkroh: which external hardware? avrs and arms need a bypass cap and an oscillator10:42
wpwrakwhitequark: good luck with the on-chip peripherals :)10:43
whitequarkwhich bootcode? avrs require a programmer, cortexes have swd, which is essentially same thing10:43
rohwhitequark: not neccessarily. there is a 8mhz rc inside and also a pll if needed10:43
whitequarkroh: on both of them10:43
wpwrakof course, you can use stm's peripheral lib ...10:43
whitequarkwpwrak: imo all vendor libs suck, hw companies shouldn't ever attempt to write software10:43
rohive used stm32 recently. nice for an arm, but way more complicated10:44
wpwrakthat seems to be good advice :)10:44
rohwhitequark: ack.10:44
rohabout the "hw companies shouldn't ever attempt to write software"10:44
rohthats even true for intel and co.10:44
Action: whitequark shudders10:45
rohwhitequark: not even that. check out your network drivers10:45
whitequarkroh: wired or wireless?10:45
whitequarkiwlwifi is pretty horrible indeed. still better than broadcom though10:46
rohe1000 and iwlwifi both already had bad bugs10:46
rohin hw as in sw10:46
whitequarkit has power management disabled by default10:46
whitequarkwhich is telling10:46
rohacpi and efi are a multi-vendor-crime10:46
whitequarkalso it only works well for me with swcrypto=1 which is also telling10:47
whitequark(efi) before efi, i thought bios was bad. nope, it actually was an excellent, well-designed and thought out piece of software10:47
whitequarka guy i know bricked an efi intel board and recovered it in an email conversation with intel10:49
wpwrakand then they hired beavis and butthead ... "let's break something"10:49
whitequarkwhen he explained how he did it they offered to hire him10:49
whitequarkperhaps efi is just a very contrived way to interview candidates10:50
rohever went to school? thats not where engineers come from!10:50
whitequarkroh: I could be a bioengineer10:50
rohi guess its just statistical errors now (having engineers) and when you find one, you try to hire em.10:50
wpwrakreminds 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 ?"10:50
whitequarkwpwrak: hahaha10:51
whitequarkroh: good for employment!10:51
Action: larsc develops software for a hardware company :/10:53
rohlarsc: as a freelancer?10:53
larscas a employee10:53
rohi think its only getting dangerous as long term employee10:53
larscalmost two years now10:54
rohsince 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 datasheets10:54
whitequarkroh: wait, why would anyone *want* to hinder people on that?10:55
rohe.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.10:55
rohwhitequark: intel seems to do that. atleast i know of no other way to write that stupid code.10:56
rohalso 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 hardware10:57
larscI don't think not reading datasheets for other devices correlates to writing bad code10:57
rohlarsc: 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 same10:57
rohyou know the sentence 'den wald vor lauter baeumen nicht sehn'?10:58
whitequarkofftopic: it's an exactly same idiom in russian (and apparently english)11:00
larscnow we are talking about bad design11:01
larscyou can still write good code for a bad design11:02
larscit's different layers11:02
whitequarkmost code by hw vendors I've seen was written like an afterthought11:02
whitequark"yeah, and now let's cobble some procedures together to configure our perfect core"11:03
whitequarksaid to a first-year intern11:03
rohlarsc: 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.11:04
rohusually it ends up with 'the guy who gets documentation access has written 10 drivers for 5 vendors and knows his framework'11:05
rohcompared to 'the guy from the vendor is learning how to write his first kerneldriver ever from a book now'11:05
rohsure. there are good and bad examples for both ends of the spectrum. there is what ive seen live to often11:06
larscIf only people who already have already written 10 drivers get to write drivers, you'll never get new people to write drivers11:06
whitequarkyou probably shouldn't ship drivers written by complete novices without any modification though11:07
larsc'proper code review' is the catchphrase here11:07
rohlarsc: true. but i guess you know what i mean. the 10 drivery already guy is a freelancer or short time employee on project basis11:07
rohthe 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 inhouse11:08
rohsame is true for non-linux platform drivers as well.. i can show you a few examples when we meet at some point (win32 driver sources11:09
larscI'm not even sure I want to see that ;)11:09
rohcode review. nice idea. never seen that at a hw vendor.(yet)11:09
rohlarsc: hrhr. true11:10
larscwe do code review11:10
larscor well I do code review11:10
rohhehe.. where you working at?11:11
larscAnalog Devices11:11
rohnice. also i must say, i havent heard anything bad.. which is a good sign in that business i guess11:11
rohcan you tell what kind of devices you usually write drivers for there?11:12
rohwow. long list11:14
larscand due to good design we are able to reuse the same driver for multiple devices11:15
rohi guess thats where you differ to the typical inhouse coder already. they seem not even to care for something like that (code reuse)11:17
larscI'm makeing myself obsolete (like any good engineer ;) )11:20
wpwrak(driver reuse) gcc -DADP8861 -c lars.c11:29
wpwrakroh: 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.11:30
rohwpwrak: exactly. thus it never gets reviewd, debugged, fixed, or security-patched11:34
whitequarkI really wish LLVM compiled faster11:53
Action: whitequark probably spends half of his time compiling LLVM these days11:53
larscare you compiling with gcc or with llvm? ;)11:54
whitequarkthe debian package prefers gcc11:55
whitequarkthough by now, the time spent compiling it would probably be bigger than time required to figure out how to adjust the package11:56
pcercueicompiling mipsel-linux-llvm? :)11:56
whitequarkpcercuei: arm-none11:56
whitequarkwell, there's no such thing as cross-llvm, but I use it for arm-none-eabi.11:57
cderoh: what does hrhr mean?13:37
larscnot 1)13:45
wpwraknaw. it's the shortened professional form of ballmer's "developers ! developers !". it's "human resources ! human resources !"13:47
ysionneauhttp://mailman.cs.huji.ac.il/pipermail/linux-il/2013-September/010649.html :o13:50
larscso basically userspace in ring113:54
larscbut makes sense13:54
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 ?14:02
wpwrakthough 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.14:03
larscwhy not javascript?14:04
wpwrakisn't that, like, very 2012 ?14:05
larscso a robust technology14:06
whitequarklarsc: https://github.com/charliesome/jsos/14:11
mthC++11 feels like a new language14:11
whitequarkwpwrak: http://www.netcobol.com/14:13
whitequark... which is precisely, down to every word, what you asked for. :D14:13
Freemorwpwrak: I still have nightmares of bubbling in: 02 filler pic ...14:13
Freemorand waiting in terrified anticipation for the card reader to mangle and jam on sone card in the middle of the deck14:16
wpwraktoo cool ;-) reality mimicking and even mocking sarcasm :)14:17
whitequarklarsc: though charliesome is generally a good fellow, that's a joke project14: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 ?14:19
Action: Freemor feels old14:20
Freemorbut then 48 is like 100K in computer years14:23
viricFreemor: you must be one of those who invented the computers14:27
Action: whitequark . o O ( EWD )14:31
wpwrakhmm, a ~1965 model. that would be about 1 petacycle at the computer technology of that time14:32
Freemorno, 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.14:42
wpwrakwho needs ZIP if you have ARC ?14:43
wpwrakand 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 (!) line14:44
Freemori miss xmodem (in that naustalgic don't really remember how bad it was kinda way) 14:45
Freemorbefore that all we had was the equivelent of cat foo > /dev/ TTyS0 and pray14:47
viricI remember the choice xmodem, ymodem, zmodem.14:48
viricwas zmodem the best?14:48
Freemorhad things like resuming a failed transfer and better thru put14:49
viricI remember I was reverse engineering the cool interlnk.exe/intersvr.exe, to implement a linux side14:49
viricFreemor: I remember zmodem resisting errors14:50
Freemorzmodem was nice14:51
Action: Freemor still has a 56k v42bis full hardware modem around14:52
Freemorno acoustic coupler tho :)14:54
whitequarkI know a guy who still uses zmodem17:23
whitequarkzmodem is at least two times older than him17:24
viricwhitequark: retro trend17:54
whitequarkviric: he wanted to upload firmware to an fpga via uart or something17:55
whitequarkargh, I just bricked a completely new jlink clone18:23
viricwith ruby?18:27
whitequarkturned it on and ran segger's gdbserver18:28
whitequarkit attempted to automatically update the firmware. that NEVER works.18:28
cdeyou gdbserver tries to update the firmware? wierd18:28
whitequarkthat's how jlink tools work18:29
apeleteviric: you were right about this morning, using the gdb coming from the toolchain and built for mips target solved it20:25
apeletehere is a gdb session with the debian x86 gdb: http://paste.debian.net/42536/20:26
apeletenow debugging same executable with gdb for mips target: http://paste.debian.net/42540/20:28
apeleteviric: I can start debugging properly now, thanks again for the help20:33
viricyou are welcome20:36
DocScrutinizer05http://bellard.org/dvbt/  :-D22:04
apeleteadding kgdbcon to boot params works well too: http://paste.debian.net/42597/22:18
DocScrutinizer05whitequark: zmodem still is standard for a lot of things, like transfer of firmware images to flash devices22:19
--- Thu Sep 19 201300:00

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