<GitHub116>
[linux-milkymist/master] lm32: Disable interrupts while restoring irq and syscall stackframe - Lars-Peter Clausen
<larsc>
looks as if it is finanly stable, at least my stress tests don't crash anymore
<wolfspraul>
nice, I should mention that in the news I guess
<wolfspraul>
which linux version is this actually?
<larsc>
3.0
<Alarm>
when I load a file "patch" with the command 'first patch', I always get the message 'No patches found' when click on Go?
<larsc>
lekernel: uart "thru" mode is loopback?
<lekernel>
yes
<lekernel>
Alarm, use "configured" mode
<lekernel>
or use the patch editor
<aw>
rc3 status: all reworks done, next to clean all.
<Alarm>
k thank you. It works.
<Alarm>
For FTP, DHCP is not working? I set to manual IP address
<lekernel>
dhcp is working, or should be ...
<wolfspraul>
aw: phew, great!
<roh>
uh. aw. you are fast
<roh>
:)
<aw>
roh, :) try to test them tomorrow. my soldering status will be approved then. before each board gets test surely I need to visually inspect and measured myself. :)
<roh>
i should hurry up completing the glueing today
<aw>
roh, sounds good news from you. :)
<wpwrak>
roh: new job title: "glue sniffer" ;-)
<lekernel>
found a wiki engine that sucks more than mediawiki: the redmine wiki
<lekernel>
in fact, I wonder what is worse, spam dousing or the most obscure syntax ever
<GitHub141>
[linux-milkymist/master] lm32: Speed up aligned memcpy - Lars-Peter Clausen
<GitHub141>
[linux-milkymist/master] ASoC: Update milkymist platform to the current API - Lars-Peter Clausen
<Alarm>
What procedure must be followed to program the keys of RC5 remote control?
<wolfspraul>
Alarm: do you have an RC5 control that works?
<Alarm>
yes
<Alarm>
philips
<wolfspraul>
did you test it with m1?
<Alarm>
m1?
<wolfspraul>
you go to the IR remote dialog, and press a number on your remote, say '5', you should see the value 0x05
<wolfspraul>
Milkymist One
<Alarm>
:)
<wolfspraul>
did you try that?
<wolfspraul>
you see the correct number?
<Alarm>
no
<wolfspraul>
I'm asking because the rc5 implementation in the Milkymist SoC right now is very timing sensitive, and will not be as robust/flexible as other rc5 implementations
<wolfspraul>
so it's a bit hyperbole to call it 'rc-5' actually :-)
<wolfspraul>
it's most like "some rc-5" right now
<wolfspraul>
we changed the timing to match the remote we are including with future units, but now some other remotes don't work anymore
<wolfspraul>
the best would be a more robust rc-5 implementation but that's a lot of work and nobody sees it as enough of a priority...
<Alarm>
c'est  aleatoire
<lekernel>
on the other hand, it could work with non-RC5 remotes as well by changing the code
<wolfspraul>
Alarm: if you have a philips, maybe if you go back to the old value your remote will work again
<Alarm>
it is an old remote a philips DVD player
<wolfspraul>
do you know how to build the SoC from source?
<wolfspraul>
you can try changing that one value back and maybe you are lucky :-)
<wpwrak>
wolfspraul: no, don't make a better rc5 implementation. make a universal detector that doesn't even try to "understand" the code
<wolfspraul>
we tested a lot of remotes, like 10-15 (all rc5), and with old or new setting _some_ will work, some don't
<wpwrak>
wolfspraul: lekernel promised me one of his old M1 boards if i hack that part. so maybe it'll happen one day ;-)
<wolfspraul>
ok the more flexible you want to make it the more work it will be
<lekernel>
not necessarily
<lekernel>
if it's generic, it can overcome pesky problems like timing variations between remotes
<wpwrak>
more flexible would actually be much simpler :)
<wolfspraul>
alright, I rest my case
<lekernel>
it's less annoying testing
<wolfspraul>
I'll write it on my Santa Claus wishlist this year
<wpwrak>
dons the red pointy hat
<roh>
  ~.
<roh>
re
<aw>
rc3:Â Â clean done. Let's test impedance tomorrow. :-)
<larsc>
whoa, linux has survived 8h of constantly spawning and exiting processes on the mm one board. that's like the first time ever
<lekernel>
larsc, shall I create a repository for openwrt?
<lekernel>
larsc, this is cool, congratulations :)
<wpwrak>
fun idea: if you have a display wall made up of several LCD/plasma screens, perhaps a set of M1 could be used to display things across these screens. would need the ability to pretend do render things off-screen, e.g., if a particle crosses from one screen to the next, M1 #1 would first render it in its visible area, while M1 #2 would pretend to render (tracking the motion) but doesn't show anything. then, when the particle crosses, the
<wpwrak>
roles would be reversed. also needs the ability to synchronize rendering clocks with reasonable accuracy (i guess you could be a few pixels off without anyone noticing, though)
<kristianpaul>
is not that something very common in concerts?
<wpwrak>
should be, yes. and the equipment is probably quite $$$ :)
<wpwrak>
M1 could be a super low-cost alternative if you can find some suitable panels :)