<kyak>
xiangfu: btw, mocp is working just fine for me, with the Makefile in git (only removed the BROKEN tag)
<kyak>
it complains about terminal size, however.. But doesn't segfault
<xiangfu>
kyak: oh.. hmm.. I only test in my laptop. which the .config is different. I will try in buildhost.
<xiangfu>
kyak: I will try to find out why.
<kyak>
xiangfu: i didn't try on buildhost, too..
<kyak>
xiangfu: seems that stardict builds its own version of libsigc, and links against it. And it causes some problems for me. I tryed adding libsigcxx to stadict's dependecies, this should help (i hope)
<kyak>
in the full build, it uses libsigc from openwrt
<kyak>
also, when building stardict in minimal build, i foudn that it lacks for libstdcpp dependency
<xiangfu>
kyak: oh. good job :)
<kyak>
but.. this can be confirmed only in the evening :)
<xiangfu>
I just send out some email to u-boot, send ben nanonote patches to upstream :)
<kyak>
oh great! is our u-boot very far away from upstream?
<xiangfu>
kyak: yes. it's eating time for me. I will be back in ~ 1 hour. talk to you later. sorry.
<kyak>
bon appetit!
<xiangfu>
kyak: Ingenic's u-boot very far from upstream. ours much much better. :)
<kyak>
would be nice to get rid of u-boot some day :) and use grub
<lekernel>
why?
<kyak>
because uboot needs specially built uImage and uboot doesn't provide a great flexibility (menus, editing kernel cmdline etc) , like grub does?
<xiangfu>
1. run /usr/bin/fw_setenv_default  which write the default u-boot envs to nand.
<xiangfu>
2. using fw_setenv bootargs .... for set the cmdline.
<xiangfu>
kyak: I think we should create a package like "nandnote-full-system-files", put all gmenu2x, ... all files not rewrite openwrt base file to this package.
<kyak>
viric: as i remember, "dict" is gtk1, and gtk1 can't work with framebuffer (needs X)
<kyak>
xiangfu: yeah, we can use the fw_setenv_default for that, but with grub it's just easy as pressing 'e' during boot. and the menu?
<viric>
kyak: 'dict' is a server program
<viric>
kyak: and it comes with a console client
<xiangfu>
kyak: hmm.. then we must write keyboard and lcd driver for grub.
<kyak>
xiangfu: i think it is better to move such files to relevant packages. The files that are not a part of some pacakge, can be left as they are? (like /etc/inputrc)
<viric>
kyak: you can install other clients too.  It works through serving in tcp/localhost.
<xiangfu>
kyak: compare to grub. maybe kboot is much better.
<kyak>
viric:Â Â ah ok.. need to have a look
<kyak>
xiangfu: maybe! i never really tried anything except for grub/lilo
<kyak>
viric: put a word "60;N78" in your accentizer, it won't work ;)
<viric>
kyak: eh... :)
<kyak>
xiangfu: hm, i didn't think it was so hard.. a special driver for keyboard/lcd for grub?
<viric>
kyak: did you notice that you can click on words?
<viric>
(in the 'accentizer')
<kyak>
uep
<viric>
I think it's a great tool... but I failed to spread it.
<xiangfu>
kyak: I am not sure about grub. I just want say. if we can write those driver for grub, then we can write them for u-boot. if you have a keyboard in u-boot. then you can easy edit just as grub :)
<kyak>
the tooltip is a little bit over the word though
<kyak>
in firefox
<viric>
kyak: I only learnt the very very minimal javascript+css for that ;)
<viric>
I use the akcentiga almost always I need to read anything in Russian
<viric>
(I wrote it some years ago)
<kyak>
hmm, i didn't realize it is hard to put accents for foreigners.. but i guess, yes, it is hard.. there are not general rules for that, a lot of excpetions :)
<xiangfu>
kyak: since the gmenu2x store in projects.qi-hardware.com, maybe we just put all files/usr/share/gmenu2x/* to gmenu2x.git
<kyak>
xiangfu: having menu in u-boot would be cool ;)
<viric>
kyak: My sixth sense for guessing the accent usually puts the accent in a totally wrong position ;)
<viric>
kyak: and it's very hard to find texts with accents marked.
<kyak>
xiangfu: do you think maybe it is better to have those files in gmenu2x in openwrt-packages?
<xiangfu>
kyak: my plan on u-boot is first send to upstream  then add new feature, so we stop add new thing to u-boot. (I am a little slow on send ben nanonote to upstream :-(
<kyak>
viric: believe me, there are a lot of native speakers who are putting wrong accents
<viric>
I imagine. But not on almost every word I imagine. :)
<kyak>
usually other people laugh in their faces
<kyak>
no, not like that ;)
<viric>
having a quick dictionary like that of clicking the words also helps a lot.
<kyak>
xiangfu: this is a good plan!
<viric>
And it's no client-server interaction.. the HTML has all the dictionary definitions. You can save the html and have the click-code working
<kyak>
xiangfu: i think putting gmenu2x files in gmenu2x.git will lead to mixing between source code and configs... I think configs need to be provided by gmenu2x in openwrt-packages
<kyak>
xiangfu: btw, you've shown a nice way of postinstall handling (in nightsky). There are still files in /root that need to be moved to relevant packages (like netsurf and mplayer)
<kyak>
i don't know what to do with /root/.vimrc though :)
<kyak>
vim is from openwrt
<xiangfu>
kyak: yes I will work on the move those files to relevant packages.
<kyak>
or /root/.tclshrc
<kyak>
ok, great!
<xiangfu>
kyak: I also not sure about .vimrc .tclshrc . let's keep it in files/ for now.  the plan is stick upstream as much as possible.
<kyak>
yes, they live in file/ just fine for now..
<kyak>
hmm, i just noticed there is a qstardict
<kyak>
taking into account that cyrillic input is working in Qt, might be a better choice than stardict
<viric>
xiangfu, larsc: yesterday I had a problem on 2.6.35
<viric>
Leave a cpu intensive program run for more than 10 minutes
<viric>
(maybe others can do the test)
<viric>
And check its 'user time' and 'cpu time' (/proc/PID/stat some numbers there)
<viric>
After more or less 11 minutes, the user-time counter stops, and all gets added into the system-time counter.
<kyak>
viric: yes, Qt can run on top of directfb
<viric>
A usual cpu intensive program you can run is "openssl speed"
<viric>
It checks the 'user-time' counter to display the cpu time passed
<viric>
and after 11 minutes of running, it starts saying 0.0;
<viric>
monitoring with strace, I see that what accumulated as user time, it goes to system (kernel) time and the user-time counter stops.
<viric>
Different runs make the stopping moment vary. But it's always between 10 and 11 minutes, for what I tried. I tried with gzip and openssl speed.
<viric>
Can someone put his nanonote with the heavy job of 'openssl speed'?
<viric>
Is there a report of what is ready for the nanonote in 2.6.36?
<viric>
maybe noone here has a running nanonote? :)
<viric>
xiangfu testing 'nerase', kyak with qemu, ... :)
<kyak>
nanonote? i heard someinth about it..
<kyak>
:)
<bartbes>
viric: running? :O
<bartbes>
:P
<viric>
hehe
<viric>
I mean with an OS there and able to run programs
<viric>
I'll try to build a 2.6.36 kernel
<viric>
for i
<bartbes>
maybe I do..
<viric>
t
<viric>
bartbes: could you make it run for 11 minutes (at least) "openssl speed"?
<bartbes>
if you keep the time, I'll surely forget
<viric>
well
<bartbes>
no openssl installed?
<viric>
you can make it run until it finishes :) It may take around 20 minutes.
<viric>
ah you don't have openssl?
<viric>
bad.
<viric>
sooo
<kyak>
openssl binary is not installed, yes
<viric>
another thing. Try to make it run:Â Â gzip </dev/zero > /dev/null &
<viric>
kyak: I cannot reproduce the trouble in 2.6.36 malta, btw.
<bartbes>
viric: alright, it's doing that
<viric>
bartbes: then, note the gzip PID, and paste from time to time /proc/PID/stat here.
<bartbes>
and now we wait
<viric>
(a line with numbers)
<bartbes>
ugh, time for ssh, so I can copy-paste
<viric>
ah
<viric>
bartbes: you can run:Â Â cat /proc/PID/stat | cut -d ' ' -f 12,13
<viric>
that will choose the numbers I want to run
<viric>
17827 = user jiffies = 178.27 seconds of user-mode time
<viric>
917 = system jiffies = 9.17 seconds of kernel-mode time
<viric>
So what I see here is that, around 64000 jiffies (640 seconds), the user-mode time jiffie counter STOPS, and then all the time goes to the system jiffies (kernel mode time)
<bartbes>
27413 1388
<viric>
looks fine.
<viric>
let's wait for the 640 seconds
<viric>
bartbes: what kernel you run btw?
<bartbes>
ehm..
<viric>
(thank you very much for the test)
<viric>
uname -a
<bartbes>
root@BenNanoNote:~# uname -a
<bartbes>
Linux BenNanoNote 2.6.32.10 #1 PREEMPT Tue Jun 15 17:53:33 CEST 2010 mips GNU/Linux
<bartbes>
yeah did that already
<viric>
ok
<viric>
good test then.
<bartbes>
36223 1834
<viric>
that looks fine. user time increasing a lot, system time increasing little.
<bartbes>
so ehm
<kyak>
bartbes: you are good to update your system :) pretty old summer image
<bartbes>
apparently you know
<bartbes>
what are those time values supposed to be anyway?
<bartbes>
kyak: well did SDL get fixed?
<viric>
bartbes: user time in centiseconds, and kernel mode time in centiseconds
<kyak>
bartbes: hm, did it get broken?
<bartbes>
well yeah, but is the meaning of it?
<bartbes>
kyak: it did, sometime
<viric>
bartbes: How much time the process is spending CPU time in user-mode, and how much time the process is spending CPU time in kernel-mode (inside system calls)
<kyak>
bartbes: should be fine in the last testing image
<bartbes>
kyak: no stables coming up?
<bartbes>
46725 2339
<viric>
(I'm building 2.6.36 to test if I also see the problem therE)
<wolfspraul>
I saw a machine once at a lense maker, I think it was some sort of thin film as well, not sure
<lekernel>
wpwrak_: right now I have friends who got hands on vacuum pumps (2 primary pumps, 1 mercury (!) diffusion pump, 2 turbomolecular pumps and even one ion pump)
<lekernel>
i'm going to check that out mid January
<lekernel>
I also found an old evaporator from the 70s that no one uses and I can play around with... problem it weights hundreds of kg and is 1500km from where I live
<wolfspraul>
what do you plan to build?
<wolfspraul>
(or manufacture)
<lekernel>
mess around with semiconductors, OLED displays, etc.
<lekernel>
nothing commercial, just a fun hobby
<wolfspraul>
great
<wolfspraul>
we find a commercial application :-)
<lekernel>
hm, will be hard imo :)
<wpwrak_>
lekernel: well, we need a better lcm ... ;-)
<lekernel>
LCM?
<lekernel>
display
<lekernel>
?
<lekernel>
well manufacturing them myself won't probably be economically viable
<wpwrak_>
yes. lcd module
<wpwrak_>
naw, invent the ground-breaking technology. let other figure out how to produce it :)
<wolfspraul>
roh: you there?
<roh>
wolfspraul hey
<wolfspraul>
ah hi!
<wolfspraul>
I posted a few things for you the other day, about the m1 case
<wolfspraul>
2 boards are on the way to Sebastien, hopefully they arrive tomorrow or the next few days
<roh>
nice
<wolfspraul>
did you read what I wrote? was about tolerances I think
<wolfspraul>
worst seems to be the DC jack
<wolfspraul>
I didn't know how bad this is until I saw it now :-)
<wolfspraul>
so that one needs a lot of tolerance left and right
<roh>
eh.. nope.. email?
<wolfspraul>
in the next run we may want to tighten that a bit
<wolfspraul>
probably here in the channel
<wolfspraul>
ok let's just redo it
<wolfspraul>
you asked about tolerances
<wolfspraul>
the connectors to watch out for are: 1) DC jack 2) line-in and line-out 3) vga maybe a little
<wolfspraul>
in that order
<wolfspraul>
DC jack needs at least 1mm left and right tolerance
<roh>
ok in case of doubt i can always add some more space
<roh>
1mm is _huge_
<wolfspraul>
if you want to try, you can unsolder the DC jack on the sample you have, then you see how much wiggle room you have
<wolfspraul>
yes
<wolfspraul>
I know
<wolfspraul>
there was a back and forth about vendors, and the result is that the holes in the pcb are quite big
<wolfspraul>
unsolder your DC jack on the sample, then you see it yourself
<wolfspraul>
so DC jack is the worst
<wolfspraul>
after that - line-in and line-out
<roh>
well.. its a dc jack.. i think the contacts are quite normal (the holes)
<wolfspraul>
yes 'quite'
<wolfspraul>
but when you go into the details and tolerances well there are still differences
<wolfspraul>
just unsolder and see yourself :-)
<roh>
lets just try some boards in plural and see how it comes out
<wolfspraul>
you can try the same for line-in and line-out
<wolfspraul>
ok up to you
<wolfspraul>
unsoldering the DC jack will give you a quick idea
<kristianpaul>
i hope i wasnt too hard on those mails
<wpwrak_>
kristianpaul: naw. you're right. carlos should be in a very good position to post about "interesting" things. so if he doesn't do it, he shouldn't complain that others are filling the void
<kristianpaul>
wpwrak_: you'were righ about your comments yday
<kristianpaul>
testing now, i got the SPI to parallel now, but still missing SYN part i hope get it soon
<wpwrak_>
kewl. can you use DMA with that parallel interface ? i haven't examined the fancier GPIO features yet, but I would suspect that you can't.
<kristianpaul>
hmm close but now i'm missing 4 nibbles per convertion :S
<kristianpaul>
(fianlly got an esy way of use scp and not deal with www permisions :))
<wpwrak_>
kristianpaul: downloads.qi-hardware.com works quite nicely, too ;-)
<kristianpaul>
ahh well
<kristianpaul>
thats for the dumps for sure :)
<wpwrak_>
the problem may be that you're using values > 3. given that you get a sync every 4 clock cycles, that can't work
<wpwrak_>
so one has to give ...
<wpwrak_>
(well, or at least that's what it was like a while ago)
<kristianpaul>
i realy need a verilog boof for chrismass after this
<kristianpaul>
ah, wait i can move an if some where
<kristianpaul>
wait
<wpwrak_>
booK ? :)
<kristianpaul>
nah ,)
<kristianpaul>
just "following" the buying spirit
<kristianpaul>
Well i think i may be too stric, cause once i got a  sync signal i can predict next one and so on... well if i really trust hardware...
<wpwrak_>
why not just re-sync ?
<wpwrak_>
or change as follows: have an LSR and an output buffer. shift into LSR, on sync, clock LSR to output buffer.
<wpwrak_>
you need something like this anyway :)
<wpwrak_>
so SYNC is not the beginning of a data packet but the end of the previous one
<kristianpaul>
hmm  i dint consider that one
<wpwrak_>
if there's the wrong number of clocks between syncs, you get garbage. but then, you lose in this case anyway.
<wpwrak_>
if you really want to get fancy, you could have an "error" signal
<wpwrak_>
ah ... got it. but that's = vs. <=, not assign vs. <=/=
<wpwrak_>
so ...
<wpwrak_>
... out = shift_reg; shift_reg = { data,shift_reg[WIDTH-1:1]}; ...
<kristianpaul>
ah yes
<kristianpaul>
sorry
<kristianpaul>
assign is used for wiring to real world actually
<kristianpaul>
thats why i now
<kristianpaul>
s/why/what
<kristianpaul>
s/now/know
<kristianpaul>
argg typo
<wpwrak_>
isn't the "real world" part something that's in the declaration ? (not sure)
<wpwrak_>
i have a book on verilog, and it says that "assign" basically overrides assignments with <= and =
<wpwrak_>
the example being a reset signal: while reset is asserted, you want to force the output to a given value, even if there's a clock or any other change of input
<kristianpaul>
hmm you got me on that, i'm learning verilog btw ;)
<wpwrak_>
so when reset gets asserted, you "assign" the reset value. when reset gets deasserted, you "deassign" it. if anything else tries to change the value with = or <= while "assign"ed, nothing happens
<wpwrak_>
or at least that's how i understand it :)
<wpwrak_>
don't worry, i don't even know verilog. i just have a book :)
<kristianpaul>
The assign and deassign procedural assignment statements allow continuous assignments to be placed onto registers for controlled periods of time. The assign procedural statement overrides procedural assignments to a register. The deassign procedural statement ends a continuous assignment to a register.
<kristianpaul>
space.gif
<kristianpaul>
ops
<kristianpaul>
I need read mre
<kristianpaul>
hmmm i may want to do a 16bit register at once in order to save time
<wpwrak_>
sounds like the great return of the counter :)
<wpwrak_>
16 bit shifter, count to 4 syncs, then out = shift_reg
<wpwrak_>
or use a multiplexer. not sure which is more efficient.
<kristianpaul>
neither me, actually thats  a question for xilinx eng
<wpwrak_>
don't you get some chip resource usage info when you do the synthesis ?
<kristianpaul>
sure
<kristianpaul>
i can do becnhmark later
<kristianpaul>
also i get timings
<wpwrak_>
then you can just implement both and see which comes back smaller
<kristianpaul>
sure
<kristianpaul>
okay 16 bits looks good also to take the whole A port
<kristianpaul>
but  thats not valid for a ben.. if i may want try on it later..
<wpwrak_>
for then ben, you could implement SDIO ! ;-)
<kristianpaul>
thats 8 bits?
<kristianpaul>
or 4..
<kristianpaul>
i always ask the same :/
<kristianpaul>
let see
<wpwrak_>
4 bits + clock + command
<kristianpaul>
ah ok i'll stick on 4 and let that work (16bit) to sofware
<wpwrak_>
for sdio, things get a little more complicated ... e.g., the clock comes from the host
<kristianpaul>
hmm
<wpwrak_>
so you may need a buffer for the whole block
<kristianpaul>
yeap
<kristianpaul>
whats the clock rate?
<wpwrak_>
but that's something you don't have to worry about now :)
<kristianpaul>
yeap
<wpwrak_>
there are several clock rate ranges. the host gets to pick what it likes.
<kristianpaul>
ok i'll wire it later, well on fpga i already wired SiGE and ANT cable :)