Topic for #qi-hardware is now Copyleft hardware - http://qi-hardware.com | hardware hackers join here to discuss Ben NanoNote, atben / atusb 802.15.4 wireless, and other community driven hw projects | public logging at http://en.qi-hardware.com/irclogs
cladamw has joined #qi-hardware
Ayla has quit [Quit: leaving]
xiangfu has joined #qi-hardware
Openfree` has quit [Ping timeout: 265 seconds]
emeb has quit [Quit: Leaving.]
Openfree` has joined #qi-hardware
wej has quit [Ping timeout: 272 seconds]
<kristianpaul>
DocScrutinizer05: did you finally get usb host support for N900?
wej has joined #qi-hardware
<DocScrutinizer05>
kristianpaul: ???
<DocScrutinizer05>
h-e-n hostmode? since ages
<kristianpaul>
eww :)
<DocScrutinizer05>
hm?
* DocScrutinizer05
thinks there's something got lost in translation
<kristianpaul>
he, sorry just found a cheap n900 on local ebay
<DocScrutinizer05>
yeah, and France forbids pgp-encrypted emails afaik
<DocScrutinizer05>
age old saying: "if guns are outlawed, only outlows will have guns"
<DocScrutinizer05>
outlaws*
<Ayla>
never heard about that
<DocScrutinizer05>
applies to security/encryption technology even better than to guns
<Ayla>
PGP-encrypted mails are legal here
<Ayla>
where did you read that?
<DocScrutinizer05>
Ayla: been a long time ago, maybe they planned it and then decided otherwise?
<Ayla>
I doubt it, seriously
<DocScrutinizer05>
must've been around the same time they started to mandate for 40% french songs in radio
<DocScrutinizer05>
honestly loong ago, maybe 10 years or sth. Maybe I lack to recall correctly
<DocScrutinizer05>
anyway regarding skype, since USA forced a backdoor into it, it's actually embarrassing to outlaw it - it shows you got no clue about how to handle security stuff on a level like the "grownups" (=USA= ;-P
<DocScrutinizer05>
or the exact opposite ;-P
<Ayla>
yeah. I can totally understand why they don't trust Skype
<DocScrutinizer05>
"since US authorities may crack skype, it's not allowed to use it in Ethiopia"
<DocScrutinizer05>
anyway I feel sad about Nokia and all the new casualities
<DocScrutinizer05>
all hopes on Samsung now, for a true open phone
rejon has quit [Ping timeout: 265 seconds]
<xiangfu>
wpwrak, the atusb works fine.
<xiangfu>
but everytime it receive message through 'izchat'. there is one kernel message come up:
<xiangfu>
net wpan0: ACK requested, however AACK not supported.
<xiangfu>
do we need fix this?
<xiangfu>
another thing is . if I send message too fast. like press a then press enter. again and again. there is be :
<xiangfu>
wpwrak,(atben --- atusb) the dirtpan not very stable. compare to my other setup : (atben --- atben)
<xiangfu>
wpwrak, a lot of ping lost or DUP.
<xiangfu>
the atben --- atusb once 10 cm distance.
xwalk_ has quit [Ping timeout: 240 seconds]
cladamw has quit [Quit: Ex-Chat]
wej has joined #qi-hardware
<wpwrak>
yes, atusb has the 1 ms USB delay issue. this causes some trouble with TCP/IP. atben doesn't have such delays.
kristoffer_ has joined #qi-hardware
kristoffer has quit [Ping timeout: 252 seconds]
<xiangfu>
wpwrak, ok. got it.
<wpwrak>
the atusb problem is that "still unresolved driver issue" i've been mentioning :) basically needs a complete redesign of the way how atusb and kernel communicate
jluis|work has quit [Remote host closed the connection]
wej has quit [Ping timeout: 248 seconds]
wej has joined #qi-hardware
cladamw has joined #qi-hardware
jekhor has joined #qi-hardware
DocScrutinizer05 has quit [Ping timeout: 245 seconds]
DocScrutinizer has quit [Ping timeout: 272 seconds]
<xiangfu>
wpwrak, the atusb quiet un-stable compare to atBen.
<xiangfu>
I can only run 'ping'. but never success on 'ssh'.
<xiangfu>
but izchat works just fine. without any problem.
DocScrutinizer05 has joined #qi-hardware
DocScrutinizer has joined #qi-hardware
<xiangfu>
wpwrak, maybe I try to fix that. but the 'redesign' sound hard to me. :-)
<viric>
I bet for regs->regs[insn.f_format.rd] = value;
<larsc>
it shouldn't be modifying regs at all
<viric>
it's ldc1
<viric>
ldwc1 I mean
<larsc>
ah right
<larsc>
no
<larsc>
wait
<viric>
maybe I need an exception handler for mtc
<viric>
I added one
<larsc>
according to the spec it should be rt
<viric>
ouch, typo
<viric>
I looked at the mtc1 instruction coding :)
<larsc>
but we are writing to a floating point register
<viric>
ah yes
<viric>
then I did it fine
<viric>
it's rd...
<viric>
rt is the source
<viric>
rd (ft in the manual) the destination
<viric>
hm no. all wrong. I don't understand regs->regs :)
<larsc>
regs are just the normal registers
<viric>
where are the floating point then?
<larsc>
struct thread_struct
<larsc>
there is a function called get_fpu_regs
<viric>
and the thread_struct... where can I get it from? a static variable?
<larsc>
get_fpu_regs(current) should give you the fpu registers for the process receiving the signal
<viric>
ok
<larsc>
anyway time to get some sleep
<larsc>
good luck
<viric>
:)
<viric>
thank you a lot
<viric>
fpuregs = get_fpu_regs(current);
<viric>
fpuregs[insn.f_format.rd] = value;
emeb has quit [Quit: Leaving.]
emeb has joined #qi-hardware
<whitequark>
btw
<whitequark>
for building webkit, esp. the debug version, you'll probably need lots of stuff
<whitequark>
a recent multicore cpu, at least 8g of RAM, 64-bit OS
<whitequark>
and several hours of CPU time
<viric>
:)
<whitequark>
more precise
<whitequark>
several hours of linking time alone
rodgort has joined #qi-hardware
<viric>
due to the debug info?
<whitequark>
nope
<whitequark>
I've seen only the release version to build for this time
<viric>
umh my new kernel does not boot. perfect
<whitequark>
I've no idea how webkit devs debug it
<whitequark>
it has several millions of symbols
<whitequark>
you can get reasonable times on a machine with 64g of RAM and full tree on the ramdisk
<whitequark>
still it's exceptionally slow
<viric>
hm the release version built fine.
<whitequark>
oh, and if you turn on lto, it'll link it several hours, then determine that something in webkit prevents it from doing LTO the way it wants to do it
<whitequark>
and the linker will START OVER.
<viric>
well, turning lto should be hardcore, yes
<viric>
let's see the traps!
<viric>
ouch. illegal instruction. hell
<viric>
ah it's right
<viric>
(my first kernel patch :)
<lindi->
whitequark: debian builds webkit on real arm hardware, no cross-compiling
<lindi->
whitequark: for libv8 this actually caught some real bugs too