| wpwrak | well, you probably don't need it in this case. bah. getting tired. time for dinner. | 00:04 |
|---|---|---|
| wpwrak | ah, what was the other problem - shutdown not working ? | 00:31 |
| wpwrak | reboot | 00:31 |
| wpwrak | indeed, that's still brokebn | 00:32 |
| wpwrak | it sits in yaffs_flush_whole_cache -> yaffs_flush_file_cache | 00:33 |
| wpwrak | wild guess: yaffs is being shut down after the NOR driver ? | 00:34 |
| wpwrak | hmm. though ... | 00:34 |
| wpwrak | yaffs_flush_file_cache (obj=0xffffffff) at yaffs_guts.c:1403 | 00:34 |
| wpwrak | dev->cache == NULL | 00:36 |
| wpwrak | this system really wants an inaccessible zero page. badly. | 00:36 |
| wpwrak | grmbl. so watchpoints have a size limit :-( | 00:43 |
| wpwrak | (gdb) awatch *(struct yaffs_obj_hdr *) 0 | 00:43 |
| wpwrak | Expression cannot be implemented with read/access watchpoint. | 00:43 |
| wpwrak | interesting ... (gdb) p *dev | 00:44 |
| wpwrak | Cannot access memory at address 0x418d80d8 | 00:44 |
| wpwrak | (gdb) p dev->cache | 00:45 |
| wpwrak | $2 = (struct yaffs_cache *) 0x0 | 00:45 |
| wpwrak | what now ? :) | 00:45 |
| wpwrak | seems that gdb is too lazy to transfer such a big structure | 00:47 |
| wpwrak | bah, a meager 3684 bytes ! | 00:47 |
| wpwrak | maybe that's also the reason why stack traces always terminate so early | 00:49 |
| wpwrak | typically after 2-3 frames, with a complaint "Backtrace stopped: previous frame inner to this frame (corrupt stack?)" | 00:49 |
| wpwrak | ah. that's obviously wrong. but in this case, i don't know what to do about it | 00:56 |
| wpwrak | tentative patch sent as well. at least reboot seems to work properly. | 01:21 |
| mumptai | hi | 06:47 |
| GitHub142 | [flickernoise] sbourdeauducq pushed 1 new commit to master: http://git.io/X7ORdg | 09:51 |
| GitHub142 | [flickernoise/master] yaffs.c: ycb_fsunmount already cleans up, don't do it again in unmount_handler - Werner Almesberger | 09:51 |
| wpwrak | hmm, i kinda wonder what would happen if i just replaced that nasty linked list code with the one from linux ... | 11:05 |
| terpstra | quick question: if you strip rtems down to the minimum. how big does the rom end up as on the lm32? | 11:05 |
| terpstra | ball park | 11:06 |
| wpwrak | i guess lekernel might know. else, try and see ? :) | 11:14 |
| kristianpaul | terpstra: minimun means no shell and just a printf hello world? | 11:19 |
| lekernel | http://www.rtems.com/wiki/index.php/TinyRTEMS#Configuring_RTEMS_for_Size | 11:20 |
| lekernel | but I have not really checked... we have the luxury of SDRAM here | 11:21 |
| kristianpaul | ah true | 11:22 |
| terpstra | so 44k-ish | 11:22 |
| terpstra | we currently have only 64k of memory =D | 11:22 |
| lekernel | more 57k-ish, LM32 is closer to sparc than 68k | 11:22 |
| lekernel | you want to run RTEMS on White Rabbit? | 11:23 |
| terpstra | i am evaluating our options atm | 11:23 |
| terpstra | currently the lm32 is just running PTP over ethernet | 11:24 |
| terpstra | but we need it also to run arp and dhcp | 11:24 |
| terpstra | and maybe snmp | 11:24 |
| terpstra | so that starts to sound like an OS would be helpful | 11:24 |
| terpstra | but we are very resource constrained | 11:24 |
| lekernel | maybe this? http://www.sics.se/~adam/lwip/ | 11:25 |
| terpstra | yes, i am aware of that project | 11:26 |
| terpstra | we probably need task switching, though | 11:26 |
| qi-bot | The Firmware build was successfull, see images here: http://fidelio.qi-hardware.com/~xiangfu/build-milkymist/milkymist-firmware-11092011-1114/ | 12:05 |
| wpwrak | interesting. now it's easier to trigger the hang. am i just quicker in the morning ? :) | 12:12 |
| wpwrak | hmpf. nice. I: Booting... assertion "!the_message" failed: | 13:05 |
| wpwrak | that's even before i get to grab the thing with gdb ... | 13:06 |
| wpwrak | attaching when it's there worked, though. phew :) | 13:06 |
| wpwrak | mwalle: how do you see the possibility of overcoming gdb's apparently very small transfer size ? | 13:07 |
| wpwrak | mwalle: (see also my posting with subject "gdb data transfer limitation ?") | 13:08 |
| wpwrak | i can work around it reasonably well in the case of data, but there doesn't seem to be a sane way for processing stack frames piecewise (sane = without prying it apart manually) | 13:09 |
| lekernel | http://www.ted.com/talks/a_robot_that_flies_like_a_bird.html | 16:16 |
| lekernel | long version: http://www.festo.com/cms/en_corp/11369_11468.htm#id_11468 | 16:27 |
| kristianpaul | ah, festo, yes it looked very like that :) | 16:28 |
| mumptai | moin | 16:29 |
| kristianpaul | cool fly | 16:30 |
| kristianpaul | hi mumptai | 16:30 |
| kristianpaul | i guess battery still a problem for long flys?, also will be cool see it fly with some more wind around | 16:40 |
| kristianpaul | wondering also the kind of materials they used | 16:40 |
| Action: kristianpaul check second link | 16:40 | |
| mumptai | what is flying? | 16:44 |
| kristianpaul | mumptai: http://www.festo.com/cms/en_corp/11369_11468.htm#id_11468 | 16:52 |
| Action: kristianpaul see how usefull a CNC is :-) | 16:52 | |
| mumptai | nice | 16:56 |
| wpwrak | hmm, is it safe to increase the size of the memory regions in milkymist/software/gdbstub/linker.ld ? | 17:15 |
| wpwrak | i.e., where does the rom+ram = 8 kB limit come from ? | 17:15 |
| lekernel | it's on-chip memory, which is scarce | 17:26 |
| lekernel | also, if you change the gdbstub, you'll need to rebuild the bitstream | 17:27 |
| wpwrak | shit :-( | 17:27 |
| lekernel | (you can increase a bit the amount of memory at the same occasion, though. but try not to - it's an expensive resource) | 17:27 |
| wpwrak | hmm. let's see if i can fix the problem on the gdb side instead then | 17:28 |
| lekernel | well... the main problem with bitstream builds is the 10GB of bloatware you need to set up. once you have ISE installed, it's just one command. | 17:28 |
| wpwrak | and years of processing etc. | 17:28 |
| wpwrak | how is llhdl coming along anyway ? ;-) | 17:29 |
| lekernel | only 15-30 min on a modern computer | 17:29 |
| wpwrak | gdb-7.3.1 should be good, right ? i.e., supporting lm32 out of the box ? | 17:30 |
| lekernel | yes | 17:30 |
| lekernel | if you're using the flterm pass-through, any GDB version with lm32 support should be OK | 17:30 |
| wpwrak | kewl, thanks | 17:30 |
| lekernel | the gdb 7.3+ requirement is only when NOT using flterm | 17:31 |
| wpwrak | hehe, sometimes just reading the source helps :) | 17:42 |
| wpwrak | the magic word is set remote memory-read-packet-size 500 | 17:42 |
| wpwrak | (or something like this) | 17:42 |
| wpwrak | hmm .. maybe | 17:43 |
| wpwrak | this lets me read big variables. no luck with the stack, though | 17:44 |
| wpwrak | seems that gdb doesn't understand lm32 stack frames. hmm. | 17:51 |
| wpwrak | i guess things are compiled with omit-frame-pointer ? | 17:54 |
| lekernel | FN isn't, unless it's the compiler default | 17:57 |
| lekernel | RTEMS I don't know | 17:57 |
| wpwrak | i don't see it there either | 17:57 |
| wpwrak | and we do have a very nice frame pointer. hmm. | 17:59 |
| wpwrak | down | 18:00 |
| wpwrak | oops | 18:00 |
| mwalle | wpwrak: yeah there is a qSupported query | 18:48 |
| mwalle | which returns PacketSize=.. | 18:48 |
| mwalle | #define BUFMAX 800 | 18:49 |
| mwalle | #define BUFMAX_HEX 320 /* keep this in sync with BUFMAX */ | 18:49 |
| mwalle | i fixed this some time ago, and iirc a quick test showed that everything was working ;) | 18:51 |
| mwalle | commit id 02cdac90da6 | 18:51 |
| wpwrak | hmm, that's old enough that it should be in the SDK | 18:57 |
| wpwrak | a test would be something like this (on flickernoise): p *( struct yaffs_dev *) 0x408d85c0 | 18:58 |
| wpwrak | (any reasonably valid address will do) | 18:59 |
| mwalle | could you please show remote memory-read-packet-size before setting it? | 19:02 |
| wpwrak | The memory-read-packet-size is 0. Packets are limited to 800 bytes. | 19:02 |
| mwalle | mh is 750 working? | 19:02 |
| mwalle | 799? | 19:03 |
| mwalle | 798? :) | 19:03 |
| wpwrak | up to 799 yes ;-) | 19:04 |
| wpwrak | length < (sizeof(remcom_out_buffer) / 2)) maybe s/</<=/ ? | 19:04 |
| wpwrak | and then find a way to sneak in the \0 ? :) | 19:05 |
| mwalle | btw do you have binary downloads enabled? | 19:06 |
| wpwrak | ah, that's already there | 19:06 |
| wpwrak | no, it's all text | 19:06 |
| mwalle | mh theres a checksum at the end of the packet | 19:07 |
| wpwrak | aah, right, the checksum | 19:07 |
| mwalle | but this not written to the buffer | 19:08 |
| wpwrak | yup. generated on the fly | 19:08 |
| mwalle | are you getting E22? | 19:08 |
| wpwrak | so maybe it's really just < vs. <= | 19:08 |
| wpwrak | yes | 19:08 |
| wpwrak | btw, you don't need parentheses around sizeof(...)/2 | 19:09 |
| Action: wpwrak wonders how many bugs are overlooked in reviews due to excessive parentheses | 19:10 | |
| wpwrak | maybe we need a -Wredundant-parentheses ideally enabled by default, along with -Werror :) | 19:12 |
| mwalle | wpwrak: mh nice compiler switch :) | 19:13 |
| mwalle | wpwrak: thats not my code ;) | 19:13 |
| wpwrak | heh :) many possible culprits | 19:14 |
| wpwrak | now, what's really troubling me at the moment is that stack traces don't work | 19:16 |
| mwalle | yeah <= makes sense | 19:16 |
| mwalle | whats the last stack frame you see? | 19:18 |
| mwalle | wpwrak: do you submit a patch for gdbstub? rebuild it, copy gdbstub.rom to the proper location and submit that patch too? :) | 19:19 |
| wpwrak | i don't have the bitstream build process set up, so i couldn't test changes to gdbstub | 19:22 |
| wpwrak | *snivel* all i wanted are some nice colorful effects. and now i'm there, fixing RTEMS, poking around in the depths of gdb, ... | 19:24 |
| wpwrak | (fixing RTEMS) as in, i already have two more bugs in the queue. one fixed, the other one in need of better debugging support (hence the stack traces). the 2nd bug may be in FN/MM, though | 19:26 |
| wpwrak | (it's something trying to read from an empty queue right after the system says "Booting". sometimes, a small assert can work wonders ...) | 19:26 |
| mwalle | wpwrak: it almost never works like that :b | 19:27 |
| wpwrak | yeah, but usually the ride is a little less scenic :) | 19:27 |
| lekernel | wpwrak, and you're doing an outstanding job at it :) keep up the good stuff *g* | 19:28 |
| mwalle | wpwrak: lekernel: ok so i'll fix and test it | 19:28 |
| wpwrak | in fact, the only thing that saves the system from total collapse is that most of the RTEMS infrastructure is used very lightly. put a bit more pressure on it, and all those little oversights will go up like new year's eve fireworks | 19:28 |
| wpwrak | lekernel: thanks for commiserating ;-) | 19:29 |
| wpwrak | mwalle: thanks ! | 19:29 |
| mwalle | i like wpwrak pictured metaphors ;) | 19:30 |
| wpwrak | what scares me a bit is that some of the more dubious constructs (like the doubly linked list structure) can have subtle failure modes. e.g., if you just use the list in the "old-fashioned" way, i.e., for (p = list_first(); p; p = p->next) ..., things will almost work. the only problem will be that you get what looks like a corrupt last list element. but the pointer will still be valid, so you wouldn't even trip over that. | 19:32 |
| wpwrak | and there's a pair of examples of mixing up the paradigms right in chain.h, so the issue is less hypothetical than it may seem ... | 19:33 |
| lekernel | http://www.rtems.com/node/70 | 19:34 |
| lekernel | this code is used in those :-) | 19:34 |
| wpwrak | e.g., if you did the above in linux, where doubly linked lists are somewhat similar, you'd loop forever. that ought to get noticed :) | 19:35 |
| wpwrak | that casts an interesting light on certain "accidents" ... :) | 19:35 |
| wpwrak | err, i meant chain.inl | 19:36 |
| wpwrak | just posted it | 19:54 |
| wpwrak | i should start using quilt. the collection of patches is getting a bit messy :) | 19:54 |
| lekernel | you should post them to the RTEMS mailing list too | 19:55 |
| wpwrak | i know .. but i'm already suffering a bit of mailing list overload. so i'm trying to avoid adding more that i don't read either :) | 20:02 |
| wpwrak | besides, i very much hope we can end this misery before too long ;) | 20:04 |
| mwalle | wpwrak: could you send me a flickernoise binary with debug symbols? | 20:10 |
| wpwrak | like http://www.milkymist.org/updates/2011-07-13/flickernoise ? | 20:14 |
| wpwrak | with the flashable binary http://www.milkymist.org/updates/2011-07-13/flickernoise.fbi | 20:14 |
| Fallenou | (reading rtems ML) Ralf really is a pain. | 20:34 |
| wpwrak | "I don't see what add a cast to void* would fix." ? :) | 20:39 |
| Fallenou | I was looking at the chat between Joel and Ralf about RTEMS being dependent on GNU C compiler | 20:40 |
| wpwrak | and, towards what are they leaning ? | 20:43 |
| Fallenou | Joel is just saying it would be cool to reduce step by step dependencies on gcc in order to someday be able to compile with something else | 20:44 |
| Fallenou | Ralf is just answering like an ass as usual | 20:44 |
| Fallenou | sarcasm etc | 20:44 |
| wpwrak | hmm. moderate gcc dependencies shouldn't be a big issue. you need a major compiler for such a project anyway. and the likely candidates seem to try to be compatible with gcc anyway. | 20:45 |
| wpwrak | ah, very good. at least two patches are in. | 20:46 |
| Fallenou | sdcc pcc clang were quoted | 20:46 |
| Fallenou | Metrowerks and GreenHill as well | 20:47 |
| wpwrak | doesn't clang track gcc ? | 20:47 |
| kristianpaul | sdcc :) | 20:47 |
| wpwrak | sdcc ... i wouldn't try that ;-) | 20:47 |
| kristianpaul | i will hold my hope for while | 20:48 |
| kristianpaul | :_) | 20:48 |
| Fallenou | very nice catch about rtems linked lists | 20:48 |
| Fallenou | really crazy that such errors are still in rtems code base ... | 20:48 |
| Fallenou | and that nobody spotted it | 20:48 |
| wpwrak | yes :) | 20:48 |
| Fallenou | crazy crazy | 20:48 |
| kristianpaul | linux linux ? :) | 20:48 |
| wpwrak | also all the macro use issues | 20:49 |
| wpwrak | kristianpaul: indeed. most of this wouldn't survive first review :) | 20:49 |
| Fallenou | Is VxWorks better than rtems ? (someone knows ?) | 20:50 |
| Fallenou | better in term of code quality, memory footprint, features etc ? | 20:51 |
| lekernel | it's proprietary, no? | 20:51 |
| Fallenou | I think yes | 20:51 |
| kristianpaul | yes it is | 20:51 |
| Fallenou | but I mean, NASA uses RTEMS, I don't think NASA hates proprietary software | 20:51 |
| Fallenou | So I wonder why they use RTEMS and not some proprietary OS | 20:51 |
| kristianpaul | may be is not NASA it self, may be a thir party contract? but yes is cool see rtems in NASA | 20:52 |
| Action: Fallenou is hoping a linked list related crash won't make a missile crash into his home | 20:53 | |
| lekernel | wpwrak, btw, I've had a good share of linux problems, and I think mwalle and lars_ too. don't imagine linux is a little paradise :) | 20:53 |
| kristianpaul | Fallenou: ;) | 20:53 |
| Fallenou | lekernel: you mean linux in general ? or lm32-linux or some-arch-linux ? | 20:53 |
| lekernel | lm32 | 20:53 |
| Fallenou | ok ok | 20:53 |
| wpwrak | lekernel: dunno. it's usually been kind to me the last ~20 years :) | 20:54 |
| wpwrak | not that i hadnt't had my moments of despair searching for flaws in linked lists. didn't find any, though :) | 20:55 |
| lars_ | thats because your linux code wasn't written by theobroma | 20:55 |
| wpwrak | who's that ? | 20:56 |
| Fallenou | guys who wrote lm32 port of linux | 20:57 |
| lars_ | the inital lm32 port ;) | 20:57 |
| wpwrak | ah, i see | 20:57 |
| Fallenou | ah yes initial | 20:57 |
| wpwrak | lars_: i suppose you and your pitchfork had some fun there ? | 20:58 |
| lekernel | how's the current code btw? "only" missing 90% of the drivers? | 20:58 |
| wpwrak | and the mmu :) | 20:59 |
| lars_ | wpwrak: took me a while to get fork() stable | 20:59 |
| wpwrak | that sounds ugly | 20:59 |
| lekernel | no other niceties like shared libs not working, random crashes, linker problems etc.? | 21:00 |
| lars_ | lekernel: basically yes. there hasn't been much work done lately. starting a job probably wasn't one of my brightest ideas ;) | 21:01 |
| lars_ | except for the random crashes, that should be fixed by now | 21:01 |
| wpwrak | an mmu also helps a bit with these things :) particularly the random crashes - by catching these NULL pointers before they mess up things at weird places | 21:02 |
| lekernel | he, catching NULL pointers should be about 2 lines of verilog | 21:03 |
| lekernel | assuming the gdb system handles bus errors correctly | 21:03 |
| wpwrak | show us ! (-:C | 21:03 |
| lars_ | hehe. adding a watchpoint for 0x00 is usually the first thing i do when i want to debug weird problems on lm32 | 21:04 |
| wpwrak | right now, my "null pointer catcher" consists of awatch *(uint32_t *) 0 ... awatch *(uint32_t *) 12 | 21:05 |
| lekernel | we can easily generate a bus error on the first 256kb or so | 21:05 |
| wpwrak | this gets me at least things those pesky linked lists. it's not good for much else, though | 21:05 |
| wpwrak | s/things/things with/ | 21:05 |
| wpwrak | lars_: i just wish watchpoints could be larger than 4 bytes. or there could be more than 4 of them. | 21:06 |
| lars_ | i tink you can use expressions like <= 0x1024, but gdb will fallback to singlestepping when you use it | 21:07 |
| wpwrak | lekernel: even the first 4 kB would be great. or special-case a watchpoint at address 0 to cover a larger area. whatever. | 21:08 |
| lars_ | but, like lekernel generating a bus error would probably be easier | 21:08 |
| wpwrak | single-stepping is very un-fun :) | 21:08 |
| wpwrak | of course, it means i don't have to hurry to get my MIDI/mouse hang. but getting to the overflow, with even the most moderate amount of single-stepping (conditional breakpoint), took something like half an hour ... | 21:09 |
| wpwrak | mwalle: btw, any ideas about those stack traces ? :) | 21:10 |
| mwalle | wpwrak: mom just had dinner ;) | 21:11 |
| mwalle | (gdb) p *( struct yaffs_dev *) 0x408d85c0 | 21:11 |
| mwalle | No struct type named yaffs_dev. | 21:11 |
| mwalle | with the flickernoise binary | 21:11 |
| mwalle | arent there the structures embedded into the binary with debug symbols? | 21:11 |
| wpwrak | hmm. checking ... | 21:11 |
| wpwrak | hah, indeed | 21:13 |
| mwalle | lars_: the fork bug is fixed? | 21:15 |
| wpwrak | mwalle: seems that yaffs was built without debug symbols :-( | 21:16 |
| wpwrak | let me find something else ... | 21:16 |
| mwalle | ok :) | 21:16 |
| lars_ | mwalle: at least for me ;) | 21:17 |
| wpwrak | struct compiler_sc shuold do nicely. 87036 bytes :) | 21:18 |
| mwalle | yep | 21:25 |
| wpwrak | oh. stupid me :) reversed the assertion. freud must have been whispering BUG_ON() ;-) | 21:28 |
| GitHub179 | [rtems-yaffs2] sbourdeauducq pushed 1 new commit to master: https://github.com/milkymist/rtems-yaffs2/commit/07a447def19f511fcd229886ec0ee88bf1fa884f | 21:28 |
| GitHub179 | [rtems-yaffs2/master] Build with debug symbols - Sebastien Bourdeauducq | 21:28 |
| wpwrak | ah, thanks | 21:29 |
| wpwrak | phew. two more stack frames. | 21:43 |
| wpwrak | let's switch to code review. this has worked in the past ... | 21:56 |
| mwalle | naa timing not met | 22:07 |
| mwalle | lekernel: is there any other milkymist branch for flickernoise stable? | 22:18 |
| mwalle | other than master, which has the new uart | 22:19 |
| lekernel | you mean soc stable? | 22:27 |
| lekernel | not yet, but i'll probably create one soonish with the bus error on null pointers | 22:27 |
| wpwrak | we don't use _CORE_message_queue_Flush_support (or any of its gazillion aliases) in any way, do we ? | 22:28 |
| wpwrak | or _CORE_message_queue_Broadcast | 22:28 |
| lekernel | no, I don't think so | 22:29 |
| lekernel | at least FN and the MM driver code do not use flush/broadcast | 22:29 |
| wpwrak | good. i suspect they may all have races. but i feel way too lazy to fix these, too :) | 22:29 |
| lekernel | haha | 22:29 |
| wpwrak | and they may actually be hard to fix. because the code assumes you can do those things atomically. of course, you CAN but then, you need to do a few other things with interrupts off. such as copying messages. | 22:32 |
| wpwrak | well, all this in the absence of anything ensuring exclusive access | 22:34 |
| wpwrak | let's see if there's anything ... | 22:36 |
| mwalle | mh i guess gdb is completely broken on the master branch :( | 22:37 |
| wpwrak | nice :) | 22:41 |
| wpwrak | hmm, are you even supposed to use things like rtems_message_queue_send from an interrupt ? | 22:46 |
| wpwrak | ah, and you actually do use rtems_message_queue_flush ;-) | 22:53 |
| wpwrak | but it's in midi_open. should be harmless | 22:53 |
| mwalle | wpwrak: mh instead of submitting a patch i filed a bug ;) | 22:54 |
| wpwrak | or, rather, if there's trouble with it, it will affect the system for its entire lifetime | 22:54 |
| mwalle | maybe i find more time to look into this this weekend or next week | 22:54 |
| wpwrak | mwalle: that was for the stack trace ? | 22:54 |
| mwalle | nope the off-by-one length | 22:55 |
| wpwrak | ah, so it's not gdbstub's fault ? | 22:55 |
| mwalle | wpwrak: no its a gdbstub bug, https://github.com/milkymist/bugs/issues/29 ;) | 22:57 |
| mwalle | not on the gdb bugtracker | 22:57 |
| wpwrak | ah, so it's the resolution we talked about. why bug and not patch ? lack of time for testing ? | 22:58 |
| mwalle | yeah, and on master the uart seems to be broken | 22:59 |
| wpwrak | oh, i see | 22:59 |
| mwalle | i have to wait for a branch for the stable soc | 23:00 |
| mwalle | lekernel: btw with a non autogenerated gdbstub.rom, its impossible to cherry-pick / merge patches between two branches | 23:01 |
| Action: wpwrak needs a shower after so much RTEMS | 23:51 | |
| --- Thu Nov 10 2011 | 00:00 | |
Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!