2014-04-21T04:05:33 *** mkhoory has quit IRC (Ping timeout: 250 seconds) 2014-04-21T04:19:31 *** zoso has joined #rtems 2014-04-21T08:34:51 *** edwardk has quit IRC (Quit: Computer has gone to sleep.) 2014-04-21T09:15:06 *** zoso has quit IRC (Ping timeout: 240 seconds) 2014-04-21T10:44:56 *** gedare has joined #rtems 2014-04-21T10:55:56 *** edwardk has joined #rtems 2014-04-21T11:03:29 Hi. 2014-04-21T11:05:48 Hey. 2014-04-21T11:28:42 *** shammi has joined #rtems 2014-04-21T15:26:50 *** shammi has quit IRC (Quit: Leaving) 2014-04-21T16:04:04 *** edwardk has quit IRC (Quit: Computer has gone to sleep.) 2014-04-21T17:10:44 *** kiwichris has quit IRC () 2014-04-21T17:36:10 *** kiwichris has joined #rtems 2014-04-21T19:15:04 *** mkhoory has joined #rtems 2014-04-21T19:25:21 *** edwardk has joined #rtems 2014-04-21T19:26:56 *** mkhoory-2 has joined #rtems 2014-04-21T19:28:07 *** mkhoory-3 has joined #rtems 2014-04-21T19:28:08 *** mkhoory-2 has quit IRC (Read error: Connection reset by peer) 2014-04-21T19:30:50 *** mkhoory has quit IRC (Ping timeout: 240 seconds) 2014-04-21T19:32:26 *** mkhoory-3 has quit IRC (Ping timeout: 240 seconds) 2014-04-21T19:32:37 *** mkhoory has joined #rtems 2014-04-21T22:46:30 *** kiwichris has quit IRC () 2014-04-21T23:14:59 *** edwardk has quit IRC (Quit: Computer has gone to sleep.) 2014-04-21T23:59:01 *** kiwichris has joined #rtems 2014-04-22T00:13:47 *** gigetoo has quit IRC (Remote host closed the connection) 2014-04-22T00:14:25 *** gigetoo has joined #rtems 2014-04-22T00:18:52 *** zoso has joined #rtems 2014-04-22T00:21:12 *** kiwichri_ has joined #rtems 2014-04-22T00:22:13 *** kiwichris has quit IRC (Read error: Connection reset by peer) 2014-04-22T00:24:35 *** monstr has joined #rtems 2014-04-22T00:35:44 *** kiwichri_ has quit IRC () 2014-04-22T00:43:55 *** sebhub has joined #rtems 2014-04-22T00:58:08 *** kiwichris has joined #rtems 2014-04-22T01:26:25 *** kiwichri_ has joined #rtems 2014-04-22T01:27:39 *** kiwichris has quit IRC (Ping timeout: 252 seconds) 2014-04-22T01:57:05 good morning 2014-04-22T04:11:05 *** mkhoory has quit IRC (Ping timeout: 264 seconds) 2014-04-22T05:26:56 hi sebhub 2014-04-22T05:35:06 sebhub, hi 2014-04-22T05:35:17 beng-nl, hi 2014-04-22T05:40:03 hi kiwichri_ :) 2014-04-22T05:40:40 I have been playing with the serial stuff to see what is wrong. I can end up with no output no matter what I do and other times I get the output 2014-04-22T05:41:32 I found this comment in U-boot ... "On some OMAP3 devices when UART3 is configured for boot mode before SPL starts only THRE bit is set." 2014-04-22T05:42:52 maybe we can disable it.. but it's supposed to do that though right? 2014-04-22T06:25:18 I have added the work around but I am still having issues. I also found in the TRM in section 19..6.1 ... "Only 8-bit and 16-bit accesses are allowed for the THR_REG register. Performing a 32-bit access can result in a data abort." 2014-04-22T06:26:30 The tests link issue was adding the shared 'uart-output-char.c". I have added the get char call to console-config.c and removed the shared file from the BSP. 2014-04-22T06:31:29 *** zoso has quit IRC (Ping timeout: 264 seconds) 2014-04-22T06:53:18 *** zoso has joined #rtems 2014-04-22T07:00:16 *** zoso has quit IRC (Ping timeout: 252 seconds) 2014-04-22T07:02:47 *** narendraj9 has joined #rtems 2014-04-22T07:05:19 beng-nl, I am off now; I have tried a number of things and I have found some sleeps in the openocd init is helping but I have no idea why 2014-04-22T07:05:41 beng-nl, it fails every 2nd run 2014-04-22T07:05:43 cya 2014-04-22T07:07:51 *** edwardk has joined #rtems 2014-04-22T07:11:43 *** zoso has joined #rtems 2014-04-22T07:24:25 *** peerst has joined #rtems 2014-04-22T07:31:18 *** edwardk has quit IRC (Ping timeout: 240 seconds) 2014-04-22T07:34:37 *** edwardk has joined #rtems 2014-04-22T07:40:13 *** edwardk has quit IRC (Read error: Connection reset by peer) 2014-04-22T08:13:37 kiwichri_: got it 2014-04-22T08:13:39 kiwichri_: fails = noise? 2014-04-22T08:15:10 *** edwardk has joined #rtems 2014-04-22T08:36:26 *** narendraj9 has quit IRC (Ping timeout: 246 seconds) 2014-04-22T08:48:56 *** edwardk has quit IRC (Ping timeout: 276 seconds) 2014-04-22T09:58:15 *** sebhub has quit IRC (Remote host closed the connection) 2014-04-22T11:11:38 *** narendraj9 has joined #rtems 2014-04-22T11:33:07 *** zoso has quit IRC (Remote host closed the connection) 2014-04-22T11:46:36 *** shammi has joined #rtems 2014-04-22T12:18:41 *** narendraj9 has quit IRC (Ping timeout: 246 seconds) 2014-04-22T12:29:07 *** shammi has quit IRC (Remote host closed the connection) 2014-04-22T12:51:41 *** monstr has quit IRC (Ping timeout: 252 seconds) 2014-04-22T15:34:08 beng-nl, not sure what the reason is; I am wondering if some sort of clock (pll) is not being given time to lock 2014-04-22T17:04:28 kiwichri_: i have started looking at the rtems tester.. 2014-04-22T17:05:06 built the sparc tools and tests and it's testing them, as a baseline.. so far so good 2014-04-22T17:07:25 ok.. 1 timeout, 2 failed, 489 passed; is that pretty normal? 2014-04-22T17:07:56 for the sis bsp 2014-04-22T17:33:34 *** javamonn has joined #rtems 2014-04-22T18:18:05 *** kiwichri_ has quit IRC () 2014-04-22T18:40:22 *** kiwichris has joined #rtems 2014-04-22T18:40:59 beng-nl, yeah it is about that; I will work on the tester soon and get it to report pass and fail 2014-04-22T18:41:33 ok 2014-04-22T18:41:57 i have "successfully" run all the samples through the tester on the metal! 2014-04-22T18:42:29 "successfully" = runs ok but some tests timeout :) - but that is to be debugged, the loading and running went ok 2014-04-22T18:45:11 7/11 pass though 2014-04-22T18:53:45 ok cool, now 9/11 2014-04-22T18:54:01 and i think for pppd.exe the timeout is expected 2014-04-22T18:54:24 so it's just minimum.exe that times out because it doesn't output and doesn't hit a breakpoint.. so i guess i'm just missing an exit breakpoint there 2014-04-22T19:04:56 *** mkhoory has joined #rtems 2014-04-22T19:05:20 pppd times out 2014-04-22T19:05:31 It is not made for automatic testing ... yet 2014-04-22T19:05:46 ok 2014-04-22T19:05:57 i added a _Terminate breakpoint and now minmimum.exe passes too 2014-04-22T19:06:01 time for the big batch!! 2014-04-22T19:06:05 Have you committed the changes ? I still have been having problems with the serial port 2014-04-22T19:06:39 I am wondering if it is a Flyswatter vs Flyswatter2 issue 2014-04-22T19:06:41 i have tweaked the irq handling a bit to get these tests to pass, no uart changes 2014-04-22T19:06:56 the serial port problem - do you mean the startup noise? 2014-04-22T19:07:30 No, if I get the noise it works, if I get no noise I get nothing. The code runs. If I download u-boot over gdb it works 2014-04-22T19:07:39 oh damn 2014-04-22T19:07:44 I get serial output 2014-04-22T19:07:52 okay, so far i think i always have noise 2014-04-22T19:08:02 The only differences is the host, ie speed and the flyswatter version 2014-04-22T19:08:18 And I think you are correct it is the protocol to download over the UART 2014-04-22T19:08:20 could it be the boot rom doesn't have a chance to run? 2014-04-22T19:08:44 the openocd writes replace the MLO, not boot rom 2014-04-22T19:08:47 Yeah or the speed of the set up reg writes 2014-04-22T19:09:03 maybe something needs to settle, ie a pll locking 2014-04-22T19:09:12 waait.. the noise happens before MLO 2014-04-22T19:09:17 Yes 2014-04-22T19:09:28 cos it happens without an sd card (and without jtag) on reset 2014-04-22T19:09:37 I played around with the openocd init script and it is all before any reg writes 2014-04-22T19:09:54 right! - therefore something is screwed before then already iyam 2014-04-22T19:10:19 Must be and the only difference I could see is timing 2014-04-22T19:10:32 could it be it gets jtag-halted before the boot rom code executes, after the reset? 2014-04-22T19:10:57 Maybe but should that matter or do you think we need to let the code run a little ? 2014-04-22T19:10:58 something like that is the only thing that makes sense if the reset works at all 2014-04-22T19:11:15 Let me play. Maybe a resume, sleep then halt is needed 2014-04-22T19:11:43 a little yes :-) - i haven't needed any explicit sleep statements (used to have them) but maybe my interface is just slow enough, could be as you say 2014-04-22T19:12:17 I am not sure of the USB for a Flyswatter vs a Flyswatter2 2014-04-22T19:12:24 USB speed that is 2014-04-22T19:12:39 It is very close 2014-04-22T19:12:48 the boot rom must initialize some of the uart & pll too to let the booting work so it does seem like a good explanation.. 2014-04-22T19:12:51 what is your xm rev? 2014-04-22T19:13:00 Oh I have a different serial init routine I will send you at some point 2014-04-22T19:13:12 ok 2014-04-22T19:13:22 C1 ? 2014-04-22T19:13:27 i have a c1 rev, i really hope the different revisions aren't too touchy 2014-04-22T19:13:29 oh good :-) 2014-04-22T19:13:32 there is a sticker with that on it 2014-04-22T19:13:48 yes makes sense; well i'm satisfied if it works for you and me ;-) 2014-04-22T19:13:57 yeah same 2014-04-22T19:14:00 haha :) 2014-04-22T19:14:26 It is our big adventure anyway :) 2014-04-22T19:14:26 ok so the xm rev is no factor, that's great 2014-04-22T19:14:32 exactly :-) 2014-04-22T19:15:29 * beng-nl sings "and I would walk 500 miles ..." 2014-04-22T19:16:12 what clock speed is your jtag running at ? 2014-04-22T19:17:08 reaally slow 2014-04-22T19:17:14 um 2014-04-22T19:17:37 or so i thought.. i but i see 1000 kHz now.. i have to ask openocd 2014-04-22T19:17:53 mine is 'adapter speed: 1000 kHz' 2014-04-22T19:18:04 yeah; and mine does the init at 10 kHz 2014-04-22T19:19:15 yeah which I think is correct cause the clocks are at the reset speed 2014-04-22T19:20:10 right ok 2014-04-22T19:24:05 Did you check the TRM section 19.6.1 ? 2014-04-22T19:24:23 The bit about only an 8 or 16 access to the THR 2014-04-22T19:24:36 bit access that is 2014-04-22T19:24:47 right.. didn't read it but i got the message 2014-04-22T19:25:02 i did find out about a data abort while writing there 2014-04-22T19:29:36 huh ? Did you see one ? 2014-04-22T19:30:13 yes, while getting this code running on the bbxm (after it was already running on the bones) 2014-04-22T19:30:15 hmm ok, here is something new .... 2014-04-22T19:31:37 I have the serial code locked up with no output and stopping the target and it is waiting for the TX_FIFO_E bit to be set. I stepped the code in gdb with stepi and the first read of the LSR shows the bit is set. 2014-04-22T19:31:51 I wonder if the MMU and the caching is all ok 2014-04-22T19:32:21 halting in gdb results in OpenOCD halting the CPU and the caches are automatically flushed 2014-04-22T19:32:35 ie it makes it work. 2014-04-22T19:33:07 kiwichris: sorry i was confused, i meant a read from RHR 2014-04-22T19:33:22 might be the same thing 2014-04-22T19:33:25 hence the LSR test 2014-04-22T19:33:31 that is the workaround / elegant fix 2014-04-22T19:34:38 kiwichris: that LSR observation is bad news 2014-04-22T19:34:52 Yeah, I will go back and check the MMU init 2014-04-22T19:37:36 i haven't seen it yet.. i can't be stopped from running all the tests :-) 2014-04-22T19:37:39 they are building now 2014-04-22T19:38:26 Nice 2014-04-22T19:38:51 I will send you the fix for the broken test. 2014-04-22T19:39:24 the uart compile thing? i have it fixed i think 2014-04-22T19:40:22 aww yeah 2014-04-22T19:40:24 [ 2/492] p:1 f:0 t:0 i:0 | arm/beagleboardxm: fsdosfsformat01.exe 2014-04-22T19:40:27 first one passed! 2014-04-22T19:40:31 i won't be able to sleep now 2014-04-22T19:40:33 ;) 2014-04-22T19:40:51 haha 2014-04-22T19:41:10 patch sent anyway 2014-04-22T19:41:14 okay 2014-04-22T19:41:36 hahahahaha fantastic filename 2014-04-22T19:41:37 something to watch while you wait .... https://www.youtube.com/watch?v=NLrF_2aS_hI 2014-04-22T19:41:44 it occurs to me it is a hex number 2014-04-22T19:41:45 :) 2014-04-22T19:41:55 really ? hahahaha 2014-04-22T19:42:03 0xbcbba1 2014-04-22T19:42:13 yeah that is great 2014-04-22T19:42:44 809 * 15289.. bummer 2014-04-22T19:42:47 still great :) 2014-04-22T19:43:49 oh man oh man 2014-04-22T19:43:53 red sector.. that brings back memories 2014-04-22T19:45:39 i.. the.. what 2014-04-22T19:45:42 WHAT 2014-04-22T19:47:31 amazing. 2014-04-22T19:48:41 yeah it is pretty funny 2014-04-22T19:51:21 oh your change does more than a build fix.. i've applied it now and am rebuilding now 2014-04-22T19:51:38 i will run all the tests with the new code and new bbxm.cfg 2014-04-22T19:57:56 kiwichris: running again 2014-04-22T19:58:16 great 2014-04-22T20:03:47 I have this state as reported by OpenOCD .. "dm37x.cpu: MMU: disabled, D-Cache: disabled, I-Cache: enabled 2014-04-22T20:03:47 " and I still get the lock in the tx where it thinks there is data in the FIFO 2014-04-22T20:04:04 ie I have turned the data cache and MMU off 2014-04-22T20:07:30 *** javamonn has quit IRC (Ping timeout: 252 seconds) 2014-04-22T20:07:40 did the uart produce output? e.g. does it work if you ignore the FIFO_E bit? - that will tell us the difference between the uart really not working and the register having bogus info 2014-04-22T20:09:42 No it did not. 2014-04-22T20:10:02 ok, so the register isn't lying ;) 2014-04-22T20:10:15 the uart / uart clock is off? 2014-04-22T20:10:35 No idea. I have been able to get output and I have had it work every second time 2014-04-22T20:12:08 my 2nd test output run is looking noticeably less peachy :( 2014-04-22T20:12:54 4/7 timeouts vs 1/21 2014-04-22T20:16:18 Hmm 2014-04-22T20:18:08 I would unwind the bbxm.cfg changes. These are not correct 2014-04-22T20:18:18 ok i'll try 2014-04-22T20:18:21 The delays are causing problems 2014-04-22T20:19:28 i will experiment 2014-04-22T20:21:23 ok. I am heading out for a bit; back soon'ish 2014-04-22T20:21:45 okay 2014-04-22T20:21:58 i may be in bed .. or should be.. probably won't be ;-) 2014-04-22T20:34:18 bbq 2014-04-22T21:05:40 back 2014-04-22T21:05:58 ha, i was just on my way out :) 2014-04-22T21:06:08 hm, that bbq was random (?!) noise on my part 2014-04-22T21:06:41 i just sent a small email update 2014-04-22T21:06:48 nn :) 2014-04-22T21:14:28 great 2014-04-22T21:20:37 *** javamonn has joined #rtems 2014-04-22T23:40:20 *** monstr has joined #rtems 2014-04-22T23:56:23 *** javamonn has quit IRC (Remote host closed the connection) 2014-04-23T00:42:40 *** sebhub has joined #rtems 2014-04-23T01:18:04 *** zoso has joined #rtems 2014-04-23T01:23:00 *** kiwichris has quit IRC () 2014-04-23T01:30:54 *** zoso has quit IRC (Ping timeout: 252 seconds) 2014-04-23T01:35:06 *** zoso has joined #rtems 2014-04-23T01:47:43 *** kiwichris has joined #rtems 2014-04-23T02:29:28 *** kiwichris has joined #rtems 2014-04-23T02:42:43 sebhub, hi 2014-04-23T03:42:27 hi chris 2014-04-23T04:06:44 *** mkhoory has quit IRC (Ping timeout: 252 seconds) 2014-04-23T05:48:27 grrr automake is rubish, working on getting the tests to be conditional on the bsp 2014-04-23T06:04:55 i wouldn't do this, this BSP_SMALL_MEMORY hack works fine 2014-04-23T06:16:12 *** gigetoo has quit IRC (Remote host closed the connection) 2014-04-23T06:18:24 *** gigetoo has joined #rtems 2014-04-23T06:35:09 Joel and I discussed this and there are other cases and so we would need to add a number of these. It is just makes a mess of the code. 2014-04-23T06:35:23 I think I have a solution where the hack is in the build system 2014-04-23T06:36:36 for example all the jffs2 code does not link on mcf52235 2014-04-23T06:39:53 it makes no sense to have tests code for a test that should and can never run. What is result ? 2014-04-23T06:40:06 and I mean executable code 2014-04-23T06:47:14 *** zoso has quit IRC (Ping timeout: 252 seconds) 2014-04-23T06:48:52 *** zoso has joined #rtems 2014-04-23T06:55:57 sebhub, I have sent you a patch. The number of tests which do not build on small memory is growing and we should remove the BSP_SMALL_MEMORY hack. I added as a short term thing hoping a better solution would happen based on the build system. It never happened. 2014-04-23T06:59:05 now you have to enumerate for each test all bsps which are exceptions 2014-04-23T06:59:34 i think this makes it even more harder to maintain 2014-04-23T07:01:31 I do not think it does. It does not clutter the code with a number of defines. If it is easy why was the jff2 tests not fixed :) 2014-04-23T07:02:48 Building a test that is know never to work means the rtems-test command needs to work around the fact the test is not real. 2014-04-23T07:03:10 It is better to never build it. 2014-04-23T07:04:57 an alternative would be to detect the linker errors due to memory space shortage 2014-04-23T07:05:08 and simply skip the tests 2014-04-23T07:05:24 *** commander has joined #rtems 2014-04-23T07:05:46 anything that needs manual care of files will not be maintainable 2014-04-23T07:06:31 there are too many bsps and to few developers 2014-04-23T07:11:50 there is no automatic solution, eg jffs2 tests, a single file as a databse lets anyone clean it up; the BSP_SMALL_MEMORY is a problematic hack 2014-04-23T07:13:09 detecting linker errors across all archs is beyond my autocrap foo and will 2014-04-23T07:15:19 cya 2014-04-23T07:16:02 cu 2014-04-23T09:28:16 *** monstr has quit IRC (Read error: Operation timed out) 2014-04-23T10:02:01 *** edwardk has joined #rtems 2014-04-23T10:32:50 *** sebhub has quit IRC (Remote host closed the connection) 2014-04-23T11:17:52 *** zoso has quit IRC (Remote host closed the connection) 2014-04-23T13:02:13 *** narendraj9 has joined #rtems 2014-04-23T14:35:07 *** narendraj9 has quit IRC (Quit: Leaving) 2014-04-23T16:05:37 *** edwardk has quit IRC (Ping timeout: 240 seconds) 2014-04-23T17:16:59 *** kiwichris has quit IRC () 2014-04-23T17:38:39 *** kiwichris has joined #rtems 2014-04-23T17:57:58 *** edwardk has joined #rtems 2014-04-23T19:05:06 *** mkhoory has joined #rtems 2014-04-23T22:12:28 *** edwardk has quit IRC (Quit: Computer has gone to sleep.) 2014-04-23T22:17:24 *** edwardk has joined #rtems 2014-04-23T23:28:13 *** zoso has joined #rtems 2014-04-23T23:35:53 *** monstr has joined #rtems 2014-04-24T00:43:19 *** rtemsLogger has joined #rtems 2014-04-24T01:09:23 *** rtemsLogger has joined #rtems 2014-04-24T01:50:31 sebhub, I did not follow the matrix vs 2 vector bit of your post 2014-04-24T01:54:37 we had one vector: the bsps defining BSP_SMALL_MEMORY and another: the tests using this define 2014-04-24T01:55:00 now we have a collection of (bsp, test) pairs 2014-04-24T01:56:42 Yes. Is this a concern ? 2014-04-24T02:12:13 now have to specify more data, but its ok with these per bsp files, i like this much better than one global file 2014-04-24T02:55:06 Yeah the global file was wrong. If you look at the mix of failing tests there is no real pattern I could see. 2014-04-24T02:55:32 The nice thing about this approach is the Makefile is created so you can cd into the failing dir and run make and see the error 2014-04-24T02:58:43 yes, this is nice 2014-04-24T02:59:36 beng-nl, I have pushed a beagleboardxm bsp config (hard coded to my set up) I am using to run the tests on a real bbxm. I will report once I get the samples results; so far cxx is an ignore and pppd is currently timing out, the other have passed. 2014-04-24T03:00:16 *** kiwichris has quit IRC () 2014-04-24T03:26:52 *** kiwichris has joined #rtems 2014-04-24T03:31:36 righto 2014-04-24T04:03:26 *** mkhoory has quit IRC (Ping timeout: 255 seconds) 2014-04-24T08:41:56 *** monstr has quit IRC (Ping timeout: 276 seconds) 2014-04-24T09:54:45 *** sebhub has quit IRC (Remote host closed the connection) 2014-04-24T10:02:11 *** gigetoo has quit IRC (Remote host closed the connection) 2014-04-24T10:04:23 *** gigetoo has joined #rtems 2014-04-24T10:36:36 *** giusef has joined #rtems 2014-04-24T10:37:18 *** giusef has left #rtems 2014-04-24T10:38:25 *** edwardk has quit IRC (Quit: Computer has gone to sleep.) 2014-04-24T10:46:42 *** zoso has quit IRC (Remote host closed the connection) 2014-04-24T11:44:05 *** edwardk has joined #rtems 2014-04-24T14:12:19 *** guerby has quit IRC (Ping timeout: 249 seconds) 2014-04-24T14:13:30 *** guerby has joined #rtems 2014-04-24T16:11:38 *** edwardk has quit IRC (Ping timeout: 240 seconds) 2014-04-24T18:59:51 beng-nl, about ? 2014-04-24T19:00:18 gedare, about ? 2014-04-24T19:03:22 I am wondering about this code http://git.rtems.org/rtems/tree/testsuites/fstests/fsdosfsformat01/init.c#n173 2014-04-24T19:03:50 *** mkhoory has joined #rtems 2014-04-24T19:04:13 Should this be a 'const char* dev_name' rather than a zero length array or is this a C trick to define const char* ? 2014-04-24T19:05:12 This test is failing in the beagleboardxm test run with a mount error and I am seeing the mount_dir as junk when entering the mount call 2014-04-24T19:35:30 *** kiwichris has quit IRC () 2014-04-24T19:38:29 *** kiwichris has joined #rtems 2014-04-24T19:41:38 Here is interesting line of code ... http://git.rtems.org/rtems/tree/cpukit/libfs/src/dosfs/msdos_initsupp.c#n136 2014-04-24T19:41:48 the name is the number 3 ? 2014-04-24T19:48:10 *** guerby has quit IRC (Ping timeout: 246 seconds) 2014-04-24T19:50:01 hi kiwichris 2014-04-24T19:50:21 hi gedare 2014-04-24T19:50:35 i think the static initialization of 0-length str is ok 2014-04-24T19:50:45 yeah it would seem so 2014-04-24T19:51:32 having a const char* made the debugger behave a little better. It shows the correct value 2014-04-24T19:51:56 hm 2014-04-24T19:52:26 3 as a name is interesting. 2014-04-24T19:53:51 *** guerby has joined #rtems 2014-04-24T19:53:58 Yeah it is a little interesting. The call is failing on the beagleboardxm. I need Ben to pull the rtems head in to the repo agian 2014-04-24T19:55:04 I wonder if I can clone the rtems master and just pull the beagleboard branch from Ben 2014-04-24T19:57:34 did you guys do the hangout today 2014-04-24T20:02:23 No we did not. I did not see the invite until today and I had my back worked on yesterday and ended up sleeping in 2014-04-24T20:02:34 Put my back out playing tennis this week 2014-04-24T20:03:00 ugh 2014-04-24T20:03:10 i sprained my ankle last friday..been sitting easy since 2014-04-24T20:03:18 climbing trees ;-) 2014-04-24T20:03:23 ouch that can hurt 2014-04-24T20:03:30 oh being a kid again ? 2014-04-24T20:03:33 yup 2014-04-24T20:03:36 my doctor said... 2014-04-24T20:03:43 "how old are you? oh, that's what I like to see" 2014-04-24T20:03:52 haha 2014-04-24T20:09:29 *** edwardk has joined #rtems 2014-04-24T22:48:55 beng-nl, a number of tests are failing because the configuration table does not have enough RTEMS API semaphores defined; this is a bug in the configuration accounting somewhere 2014-04-24T22:55:08 beng-nl, looks like something in the bsp is needed to indicate termios so the termios semaphores are accounted for 2014-04-25T00:04:19 *** monstr has joined #rtems 2014-04-25T00:26:09 *** zoso has joined #rtems 2014-04-25T00:26:48 beng-nl, I have raised https://www.rtems.org/bugzilla/show_bug.cgi?id=2178 with the bug 2014-04-25T00:43:42 *** sebhub has joined #rtems 2014-04-25T02:27:33 sebhub, hi 2014-04-25T02:34:16 fixed the mrfs_fstime so this test passes now 2014-04-25T03:05:29 *** mkhoory has quit IRC (Read error: Connection reset by peer) 2014-04-25T03:10:53 *** mkhoory has joined #rtems 2014-04-25T03:22:59 sebhub, do you know why the 64bit timestamp is signed ? 2014-04-25T03:49:03 hm, i didn't notice this before, yes its curious 2014-04-25T04:01:03 *** mkhoory has quit IRC (Read error: Connection reset by peer) 2014-04-25T04:04:49 sebhub, sp2038 failure on sis is in gtime_r 2014-04-25T04:06:52 yes, this is due to a 32-bit time_t 2014-04-25T04:07:02 the year 2038 problem 2014-04-25T06:06:56 The value is recovered fine and passed into gtime_r. 2014-04-25T06:53:58 kiwichris: ahh good find 2014-04-25T06:54:46 kiwichris: i think once i start tracking down some faolure causes i will "learn a lot" ;) 2014-04-25T07:05:40 i.e. will have to dig a lot 2014-04-25T07:53:11 *** sebhub has quit IRC (Remote host closed the connection) 2014-04-25T09:20:41 *** monstr has quit IRC (Ping timeout: 264 seconds) 2014-04-25T10:12:38 *** edwardk has quit IRC (Quit: Computer has gone to sleep.) 2014-04-25T10:26:44 *** zoso has quit IRC (Remote host closed the connection) 2014-04-25T11:51:28 *** gigetoo has quit IRC (Remote host closed the connection) 2014-04-25T11:52:22 *** gigetoo has joined #rtems 2014-04-25T12:47:03 *** edwardk has joined #rtems 2014-04-25T15:53:33 *** stryx` has quit IRC (Remote host closed the connection) 2014-04-25T16:00:59 *** stryx`_ has joined #rtems 2014-04-25T16:19:17 *** edwardk has quit IRC (Ping timeout: 252 seconds) 2014-04-25T17:05:20 *** peerst has quit IRC (Ping timeout: 252 seconds) 2014-04-25T17:08:02 *** edwardk has joined #rtems 2014-04-25T18:15:05 beng-nl, some are difficult like sp2038 which is a newlib bug 2014-04-25T18:17:19 devnullfatal01 should not fail 2014-04-25T18:20:30 beng-nl, I suspect a number of fails we still have relate to console output not being output 2014-04-25T18:59:07 *** edwardk has quit IRC (Quit: Computer has gone to sleep.) 2014-04-25T20:06:10 *** edwardk has joined #rtems 2014-04-25T20:20:21 kiwichris: i see .. yes could be 2014-04-25T20:21:35 i am hoping (.. not sure actually) that some of the tests are failing because i've not enabled nested interrupts yet 2014-04-25T20:22:06 i haven't figured out how to get the INTC to behave properly for it 2014-04-25T20:23:53 hmmmm 2014-04-25T20:26:42 aha, spfatal* are failling because of the _Terminate breakpoint 2014-04-25T20:26:44 good 2014-04-25T20:28:02 (it ends the session before the END OF.. gets printed) 2014-04-25T20:28:19 but i needed (?) it to end the minimum test to end at all. maybe there's a good alternative 2014-04-25T21:51:54 kiwichris: i rebased on rtems master for your fixes and am re-running everything without the _Terminate breakpoint.. i think it will help :) 2014-04-25T23:59:24 *** Sched has joined #rtems 2014-04-26T00:06:18 *** Sched has quit IRC (Ping timeout: 240 seconds) 2014-04-26T03:35:21 beng-nl, the rtems-test with gdb requires hitting a breakpoint. I think having it parse the output to stop is a hack. I think _Terminate should be split into a couple of functions so we can set a break point. The stackchk test is an example where the output happens in a fatal error extension handler. 2014-04-26T03:42:51 *** peerst has joined #rtems 2014-04-26T04:31:56 beng-nl, ftp01 and syscall01 I think fail because again the semaphore count is wrong in the configuration 2014-04-26T04:35:43 yeap, the network semaphore is not accounted for 2014-04-26T05:49:14 kiwichris: 475/492 passed with the new rtems version and no _Terminate breakpoint :-) 2014-04-26T06:10:06 I am currently on 429 and 5 failure 2014-04-26T06:10:18 8 timeout 2014-04-26T06:10:56 I have a _Terminate patch which I am testing now 2014-04-26T06:12:24 :-) 2014-04-26T06:12:33 i pushed the rebased branch btw 2014-04-26T06:13:23 so the commit id's etc have changed, so you have to do a reset --hard or something if you want to get the current branch 2014-04-26T06:15:39 I have done git stuff to track a commitable master with your branch :) 2014-04-26T06:15:58 I put it on the wiki 2014-04-26T06:17:04 ah yes i saw that 2014-04-26T06:17:16 The _Terminate patch needs review because I have made the halt function weak. I like weak functions in this case because you can override in an app 2014-04-26T06:17:33 yes, that can be really clean 2014-04-26T06:17:52 We have shaken down a number of confdefs.h bugs which is really good. 2014-04-26T06:18:05 :-) 2014-04-26T06:18:09