<wpwrak>
hmm, a bit of cargo-cult programming in lm32.h ... nothing too serious, though
<kristianpaul>
lekernel: if i switch froma 50Mhz to clock to a 16.384 Mhz (reusing clock out for memcard), do i have to consider something about the sdram controller?
<wpwrak>
xiangfu: did you build and run the CVS version of RTEMS yet ? the one with the scheduling problem. if yes, have you been able to observe that scheduling problem ?
<wpwrak>
hmm, but doesn't the lag happen without reboot/shutdown ?
<wpwrak>
or is this something else ?
<xiangfu>
this bug also cause some input problem.
<lekernel>
wpwrak, maybe there are two bugs, or maybe not. I don't know.
<lekernel>
a 1st step would be to write a 5-line program that attempts to shutdown/reboot and debug it if it doesn't work
<wpwrak>
lekernel: i think that one will still wait for you :) i'm still chasing the MIDI/mouse hang and then i'll be after more patch control. trying that fix on RTEMS CVS was just an attempt to see if there was a low-hanging fruit we could collect on the way. alas, there wasn't.
<lekernel>
does the MIDI/mouse hang happen with RTEMS CVS?
<wpwrak>
i don't know. i'm now trying to figure out how to build the thing from sources.
<wpwrak>
"cd ../conf" ? there's no such thing. xiangfu has a build_dir. maybe you mean that ?
<xiangfu>
yes. I think so. :)
<lekernel>
I also said: "mkdir ../conf". and yes, that's probably xiangfu's build_dir
<lekernel>
it's just a regular out-of-tree build with autocrap ...
<wpwrak>
aah, sorry. didn't see that
<wpwrak>
i'll call it "build" :)
<wpwrak>
quite amazing to see how inefficient autocrap is for such a large project. the linux kernel configures in maybe 1% of the time ;-))
<wpwrak>
oh, and i found another inconsistency in cpukit/score/cpu/lm32/rtems/score/cpu.h: #define CPU_ALIGNMENT 8 vs. #define CPU_STACK_ALIGNMENT 4
<wpwrak>
comments say that CPU_STACK_ALIGNMENT must be either zero or >= CPU_ALIGNMENT. not sure if it has any ill effects, though.
<wpwrak>
and of course, CPU_swap_u16, is another fine example for how not to write a macro :) but i don't think this causes any trouble at the moment either
<lekernel>
sure, sure, we'll switch to Linux when it works :-)
<lekernel>
though I can tell you the GNU stuff isn't brilliant either, even if the kernel is generally OK
<xiangfu>
wpwrak, what kernel module of atben needs? I don't know how to add the /dev/tun0 in ben nanonote.
<wpwrak>
at "make", i get  configure: error: missing define CLOCK_PROCESS_CPUTIME_ID
<xiangfu>
wpwrak, I have add the kmod-sit/ipv6/iptunnel4 . how to make the /dev/tun0 works?
<lekernel>
ah, you need to upgrade the GCC toolchain/newlib
<lekernel>
you can use the latest binary packages from the RTEMS FTP
<wpwrak>
xiangfu: i've answered over at #qi-hardware :)
<wpwrak>
downloading ...
<kristianpaul>
lekernel: Hi, do I need to consider something about SDRAM core when changing SoC system clock?
<kristianpaul>
Or if fill the right values in setup.v all should be OKAY if the timing is met in sinthesys ?
<kristianpaul>
about setup.v of course i mean right values for CLOCK_FREQUENCY and CLOCK_PERIOD
<lekernel>
usually yes
<lekernel>
what frequency?
<kristianpaul>
81920000 Hz
<lekernel>
why? that's a small change
<kristianpaul>
well seems not at all, as i'm not using the 50Mhz osc
<wpwrak>
nice. it's compiling now. thanks !
<wpwrak>
time to "make": real 1m10.309s
<kristianpaul>
at least, i managed to have a another CSR bus with different clock doimain :-)
<kristianpaul>
wich i'm open for suguestions about how to deal with crossing clocks there :)
<wpwrak>
now ... rtems and FN are just one big image, correct ? i.e., when i rebuild FN, it'll pick up the new rtems, right ?
<kristianpaul>
one image yes
<wpwrak>
main.c:49:19: fatal error: yaffs.h: No such file or directory
<wpwrak>
grmbl
<kristianpaul>
the joy of copile FN by hand :-)
<wpwrak>
yeah :)
<wpwrak>
rtems/rtems_yaffs.c:63:1: warning: 'rtems_off64_t' is deprecated
<wpwrak>
but at least it didn't fail :)
<wpwrak>
but there's still no yaffs.h :-(
<lekernel>
what YAFFS repository are you using? you need to use the new one for the nex RTEMS
<wpwrak>
ah, i didn't switch branches. let's do that ...
<wpwrak>
that's better
<wpwrak>
okay, i see the "lag" :)
<wpwrak>
the "lag" looks like a massive loss of events
<wpwrak>
and i don't see the MIDI hang with it. but it may simply mask it.
<lekernel>
it's more than that - the shell doesn't work either
<wpwrak>
you mean the serial console ?
<lekernel>
yes
<lekernel>
btw if you just open the MIDI settings, the lag bug doesn't manifest itself, does it?
<wpwrak>
indeed. but i had problems with it from time to time also before.
<wpwrak>
i haven't tried yet without FN auto-starting a first patch
<wpwrak>
yeah, serial console seem completely dead
<wpwrak>
let's try without autostart
<wpwrak>
no lag without rendering. and the console works
<wpwrak>
and i can still kill MIDI. yes ! it's just a bit more work
<wpwrak>
well, just a little bit more work
<wpwrak>
no task seems to be running to cause the lag
<wpwrak>
at least according to rtems_cpu_usage_report
<wpwrak>
what is the system-wide clock tick counter called ? (the equivalent to "jiffies" on linux)
<wpwrak>
ah, _Watchdog_Ticks_since_boot looks good
<wpwrak>
seems that the system timer stops ticking
<wpwrak>
_Watchdog_Ticks_since_boot should increment at about 100 Hz, correct ?
<wpwrak>
i think i can answer my own question: yes
<wpwrak>
when the variable monitor causes the loss of ticks, this happens as a consequence of  rtems_task_start(sampler_task_id, sampler_task, ...
<wpwrak>
at the very end of sampler_start
<wpwrak>
if i return just before it, the system remains healthy (until i try to close the variable monitor. but it's okay if it malfunctions at that point, since i left everything in an inconsistent state)
<wpwrak>
now let's see what atrocities are being committed inside sampler_task ...
<Fallenou>
win 41
<wpwrak>
bingo ?
<Fallenou>
ahah sorry wrong irssi command
<wpwrak>
further reduction: if i remove the  ioctl(snd_fd, SOUND_SND_SUBMIT_RECORD,  in sampler_task, the loss of tick doesn't happen
<wpwrak>
but let's double-check this ...
<wpwrak>
yup, confirmed. if i just comment out the ioctl, there's no lag. now, on with ac97.c ...
<wpwrak>
aha. reducing submit_record to  bsp_interrupt_vector_disable(MM_IRQ_AC97DMAW); bsp_interrupt_vector_enable(MM_IRQ_AC97DMAW); return RTEMS_UNSATISFIED;  also produces the loss of tick
<wpwrak>
lekernel: are the ticks derived from MM_IRQ_AC97DMAW ?
<wpwrak>
heh heh
<wpwrak>
and yes, incompetence kills
<wpwrak>
let's see how things are with correct macros ...
<wpwrak>
much better :)
<wpwrak>
alas, none of this helped with my MIDI problem :-(
<wpwrak>
oh, cool. now the M1 auto-rebooted ;-)
<wpwrak>
(while hanging on MIDI) maybe that was the watchdog
<wpwrak>
RTEMS CVS with FN HEAD feels pretty good. at least my tornado derivative with (real) MIDI seems to work normally
<wpwrak>
(normally = still with the possibility of hanging the system, though it doesn't happen very often)
<wpwrak>
wolfspraul: regarding controls, there may be different styles of playing the M1: one would be "hands on", where you adjust controls quite often. the other would be "hands off", where you make occasional changes but let the M1 auto-follow the music.
<wpwrak>
in the latter case, controls that "remember" their position might actually be quite convenient, because you may forgot where you, say, last touched the pad, and when you want to make a small change later, you may hit it at a completely different location
<lekernel>
nice gems you are digging out... "nothing serious" heh
<wpwrak>
yeah, i'm starting to miss the reviewers who are usually between me and such bugs in linux. people who are complaining about it being so damn hard to get things into the kernel don't know what they're missing :-)
<wpwrak>
i kinda wonder if the MIDI hang is also a macro argument gone wild :)
<wpwrak>
btw, maybe it would be a good idea to plan for a new firmware release soonish ? there's a fair number of things that have changed since july. some may notice the difference.
<wpwrak>
i'd want the MIDI/mouse hang properly dead first, though. with the latest RTEMS, it seems to happen infrequently that you may not hit it if you don't force things, but still
<lekernel>
wpwrak, btw, I posted on the RTEMS ML about that rb thing
<lekernel>
new firmware, yes
<lekernel>
next week maybe
<wpwrak>
next week sounds good to me
<wpwrak>
(rb tree bug) thanks !
<lekernel>
i'll also fix the VGA pixel clock frequency in the bitstream... let's see if it fixes that signal detection problem
<wpwrak>
do we have "permanent" access to any equipment that exhibits VGA problems ?
<lekernel>
of course not! :)
<wpwrak>
right. that would be too easy :)
<lekernel>
there's perhaps that one projector that detected it as 2048x something... I'm not exactly sure whose it is, but I'm meeting those guys on Thursday. will check out...
<wpwrak>
ah, great
<wpwrak>
*grin* rtems/cpukit/score/include/rtems/score/bitfield.h  _Bitfield_Find_first_bit has an interesting way to dodge the bullet. of course, if there was a typo and _value became __value or vice versa, would anyone notice ? :)
<wpwrak>
but they really love their macros. even where an inline function would do the job perfectly.