<roh> 720p itself means only 'resolution'
<roh> there is some us stuff which uses YUV on analog rca jackets with something similar to 'sync on green'
<roh> so its only 3 rca jacks. analog.
<roh> used mainly in the us and asia. in europe we just used rgb and scart with csync on cvbs pin
<roh> which had the feature that the tv doesnt need to do any conversion. basically the signal directly goes to the amps on the tube-pcb, sync to the deflection circuit
<lekernel> looks great
<roh> yet the limited bandwith on an rca jack never gave proper picture. and in tft/dlp times its just a intermediate format which gets digitized, buffered and scaled anyhow.... on dvi/dlp/hdmi you usually even let the sender do the scaling and send the optimal format to the screen
<roh> the scalers on gpus are usually also much better than the ones in the display controllers (there are still some in there, but they need to be cheap)
<lekernel> i know. we'll also add your beloved hdmi at some point, don't worry :)
<roh> lekernel: nice cable.. now you just need to find out what pins it wires how. this only works with graphics cards which do more than 'normal vga'
<lekernel> but this has a bit less priority than cvbs because 1. I have rarely seen HDMI projectors 2. it needs a little PCB mod to route a HDMI connector to the FPGA
<lekernel> common projector formats are 1. VGA 2. CVBS/S-Video 3. HDMI/DVI, in decreasing order
<lekernel> pins 1/2/3 are RGB, so we could definitely use such a cable to connect to an unmodified M1
<lekernel> assuming we sort out the possible DAC resolution problem
<roh> well.. if the dacs are dc coupled it could work already
<lekernel> you need DC coupling for VGA to work already, no?
<lekernel> also, can we use the cable as a 'natural' oversampling low pass filter? :-)
<roh> lekernel: dunno.
<roh> i am just sure that we need dc coupling to simulate the sync in the dac signal
<lekernel> that should be OK
<roh> then i would buy such a cable and just try how good it works/the picture looks
<roh> my guess is one looses a bit of dynamic with a 8bit dac due to the amount in voltage the sync already 'eats'
<lekernel> you loses 26% of the dynamic range, but 140MHz oversampling would buy you 3 times the resolution
<roh> hm. well.. i guess that calls for rediscussion after trying out
<roh> hm. fsck.
<roh> shouldnt have done that
<kristianpaul> and yes i had troubles with a vga spliter !!!
<kristianpaul> i'll post details soon..
<roh> ddc?
<kristianpaul> troubles = video signal distorcionated/malformed
<kristianpaul> i'll post image soon..
<kristianpaul> still at dorkbot
<roh> is counting hundreds of acryllic spacers
<aw_> kristianpaul, what's the possible trouble?
<kristianpaul> aw_: the video technician told me about power and frecuency
<kristianpaul> i also cant run mm1 video on a big plasma screen
<aw_> kristianpaul, related to design of video? or video format.
<kristianpaul> aw_: vga video, dunno
<kristianpaul> just was a tought from the guy
<aw_> kristianpaul, hmm...got it.
<larsc> lekernel: if i use the 800x600 mode from the rtms fb driver, the image is displaced by 100 pixels or so to the left
<kristianpaul> aw_: sorry
<kristianpaul> i'll drop a mail saturday i hope, when more time i have.. 3 days workshop is energy consuming..
<kristianpaul> btw like 4 guys asked me about milkymist price and avaliabillity
<aw_> kristianpaul, no sorry. :-)
<kristianpaul> ah i dint tried last msd..
<aw_> kristianpaul, AFAIK, current only have one M1 available. others are the RC3 ones later. :-)
<kristianpaul> :-)
<aw_> I'll try latest msd today. :-)
<kristianpaul> okay bed time
<aw_> kristianpaul, oah...using splitter..good. cu nice night!
<xiangfu> kristianpaul: n8
<wolfspraul> kristianpaul: I guess this is a bug you are reporting? http://en.qi-hardware.com/wiki/File:Mm1vgaoutaftersplitter.JPG
<wolfspraul> did it work at all? A picture like this one with a functioning m1 in the background would be cool :-) http://en.qi-hardware.com/wiki/File:IMG_3638.JPG
<lekernel> larsc: press "auto setting" on your screen?
<lekernel> kristianpaul: how do power and frequency of the video signal (?!) relate to driving big plasma screens?
<lekernel> milkymist at tacheles techno party next wednesday :)
<kristianpaul> lekernel: i'm not saying it was a tought/comment from the guy was setting up video
<kristianpaul> wolfspraul: it worked with out the splitter
<wolfspraul> kristianpaul: yes, but do you think 'support' for this splitter is a missing feature/bug?
<wolfspraul> it's something worth remembering maybe, we need an issue tracker :-)
<lekernel> imo it's just a problem coming from the splitter
<wolfspraul> kristianpaul: if it worked, do you have a nice picture that shows it in action? or even video?
<lekernel> the m1 puts out perfectly standard VGA
<wolfspraul> lekernel: fine, but even then we should document it. let's keep an eye on splitters :-)
<wolfspraul> the end users only cares whether it works or not, not who is to blame, or who could or could not fix it.
<wolfspraul> so the best is if we document well
<wolfspraul> then no surprises...
<wolfspraul> to me it's a good finding, I registered 'splitters' as something to watch out for
<kristianpaul> well, it worked(http://en.qi-hardware.com/wiki/File:IMG_3638.JPG) afaik just that pic from me, but i'll ask others pics..
<kristianpaul> also this was a quick talk i just had 10 minutes to setup and talk..
<wolfspraul> ah ok. that pic looked similar to the bug :-)
<kristianpaul> no much time for take pictures..
<kristianpaul> really?
<wolfspraul> any feedback on milkymist?
<wolfspraul> what was your talk about?
<kristianpaul> yeah
<kristianpaul> milkymist in 7 minutes
<kristianpaul> he
<kristianpaul> people dont want to quit the milkydrop just to edit the patch
<kristianpaul> they found it like a lack of real time
<kristianpaul> i mean
<kristianpaul> interrupt perfomance, edit patch and run again was the critic
<wolfspraul> which is a fair point, and I think sebastien thought about a second vga interface many times already
<wolfspraul> we will not introduce it in rc3 though
<kristianpaul> hey, why the last pic looks bad? it is running a patch as usual
<kristianpaul> yes sure, just saying what other commeted
<wolfspraul> maybe I just didn't get it
<wolfspraul> no worries I am not complaining, I was just confused with the splitter bug and that pic
<lekernel> kristianpaul: yes, otoh you can prepare many patches in advance and switch them in no time, e.g. with a midi controller
<kristianpaul> yes i told that lekernel
<wolfspraul> the pic is great. if that is in fact the intended visual effect, then even better!
<wolfspraul> I just didn't know, that's why I ask.
<kristianpaul> but pople want *real* *time* editing of patches
<wolfspraul> now I know :-)
<kristianpaul> well i got that impresion
<lekernel> kristianpaul: some do, some others don't...
<kristianpaul> also asked for OSC support
<kristianpaul> lekernel: he, sure ;)
<lekernel> OSC is already built in
<kristianpaul> how they use it?
<kristianpaul> please dont RTFM now :-)
<lekernel> well, there's no documentation for it yet :)
<lekernel> so it would be "RTFS" instead :)
<lekernel> but in more friendly terms
<kristianpaul> ;-)
<lekernel> you have parameters in the patches iosc1, iosc2, etc.
<lekernel> which are floating point values you can set through the OSC interface over UDP
<lekernel> you also have a MIDI sink (i.e. MIDI transport over OSC) which gets merged with the rest of the MIDI messages coming from the DIN
<wolfspraul> kristianpaul: for that pic 3638, can you give me the exact event name and location?
<lekernel> the possibility to switch patches with an OSC command
<wolfspraul> in case I want to mention it in the news (the pic is nice!)
<kristianpaul> event labsurlab at mamm
<wolfspraul> name of event, location, date
<wolfspraul> mamm?
<kristianpaul> was just before dorkbot talk started
<lekernel> and finally, you can print text messages on the screen using another OSC string message
<kristianpaul> mamm = museo de arte moderno de medellin
<wolfspraul> aha
<wolfspraul> date was April ? 6?
<lekernel> you can try easily with the 'oscsend' utility from liblo
<kristianpaul> yup wolfspraul
<wolfspraul> is there a url for the event?
<lekernel> kristianpaul: do you have pics with the video-in patches?
<kristianpaul> i think mm1 should support the splitter somw way, well or do more test, but all laptops around dint had problem with splitter
<lekernel> kristianpaul: http://en.qi-hardware.com/w/images/5/54/Mm1vgaoutaftersplitter.JPG is blurred as well outside of the screen
<kristianpaul> i think there was just one including mm1
<kristianpaul> lekernel: i know
<lekernel> kristianpaul: what was the problem exactly?
<kristianpaul> vide-in not tested yday
<kristianpaul> image was partially viewved
<kristianpaul> i mean it was kinda zoomed
<lekernel> kristianpaul: please demo the video-in patches. they're really at the next level :)
<kristianpaul> i will, i hope flash mm1 with last firmware today..
<lekernel> kristianpaul: weird
<kristianpaul> lekernel: indeed
<wolfspraul> how long did m1 run at the event in total?
<wolfspraul> just during your talk, or for some longer period?
<kristianpaul> no more than 1 hr
<lekernel> from my knowledge splitters are simple amplifiers... can't really see how that could do that
<kristianpaul> before talk
<kristianpaul> and during
<wolfspraul> ok then I say 'demoed'
<lekernel> could be some murphy-esque interaction between splitter, projector and signal integrity problems
<lekernel> kristianpaul: what flickernoise/soc versions are you using atm?
<lekernel> 0.2/RC2 (dec2010 msd) already support the video-in
<kristianpaul> sure it tested video in just dont have the best setup up for a demo
<lekernel> ah, you're having another demo later on?
<kristianpaul> i will do more tests today i hope, and a meeting with a local VJ group saturday
<kristianpaul> i have a big screen for me all day
<lekernel> ah, cool!
<kristianpaul> but the mm1 just never got to work, the screen said no signal detected
<lekernel> you could even invite people to stand in front of the cam :)
<lekernel> what screen is that?
<kristianpaul> but i plug a small screen at works..
<kristianpaul> i'll take specs today
<kristianpaul> noo time yday
<lekernel> first time I hear about screen signal detection problems...
<lekernel> i've plugged mm1 to all sorts of screens and projectors already, without a single issue
<lekernel> is the cable ok?
<kristianpaul> ok sure !, i tested with other laptops, and NO problem
<kristianpaul> i need leve, i'll bnack ramdomly in next horus
<kristianpaul> hours*
<kristianpaul> bye!
<lekernel> grmbl
<lekernel> crazy
<CIA-8> milkymist: Sebastien Bourdeauducq master * rd8ddaca / (4 files in 4 dirs): Ethernet: workaround for permanent RX FIFO overflow bug - http://bit.ly/hE7Hdj
<mwalle> larsc: do you still facing problems on real hw?
<CIA-8> rtems-milkymist: Sebastien Bourdeauducq master * r5456116 / (3 files in 2 dirs): Ethernet: use library CRC - http://bit.ly/f2BGDr
<larsc> mwalle: nope
<larsc> now i'm facing problmes in qemu... qemu crashes as soon as the kernel has finished loading the initrd image
<larsc> PC is 0 for some reason
<larsc> btw. all the got relocations seem to be against soft-math functions http://pastebin.com/gzv9wyTh
<mwalle> on real hw too?
<larsc> mwalle: not that i can see
<mwalle> mhh
<mwalle> not good
<larsc> but i'm maybe using an outdated version of qemu
<mwalle> larsc: do you have applied the gcc-fix-lm32-libgcc.patch?
<larsc> i've applied all your patches
<mwalle> is __PIC__ undefined?
<mwalle> have a look at libgcc/config/lm32/_ashrsi3.S
<larsc> ah!
<larsc> __PIC__ is probably defined then
<larsc> btw. the latest qemu build fails with make[1]: *** No rule to make target `../ptimer.o', needed by `qemu-system-lm32'.  Stop.
<mwalle> official one?
<larsc> yours
<larsc> the milkymist branch
<mwalle> i have one fix regarding system calls
<mwalle> that is not in my repo yet
<mwalle> you could try that too
<larsc> hunk#3 doesn't apply, against which branch is the patch?
<mwalle> mh my working one here
<mwalle> i try to merge upstream and milkymist into master
<mwalle> btw, does anybody know how to avoid duplicate commits you get if your patch is merged upstream (and the commitmsg was changed?)
<lekernel> mwalle: got an idea what's happening when the board suddenly freezes and gdb shows it's executing the debug ROM?
<lekernel> some exception? how to know more?
<mwalle> how shows gdb its executing the debug rom?
<lekernel> as soon as it connects, it shows PC is in the debug rom
<lekernel> well, actually past it
<lekernel> (gdb) set remote interrupt-on-connect on
<lekernel> (gdb) target remote /dev/pts/60
<lekernel> Remote debugging using /dev/pts/60
<lekernel> 0x1f18e2a4 in ?? ()
<lekernel> looks pretty bad...
<mwalle> mhhh doenst look like a valid PC
<lekernel> yeah
<lekernel> ra is messed up too.. 0x1f18e82c
<mwalle> did you debug before?
<lekernel> no, just booted and connected GDB when it froze
<mwalle> is this a new freeze (introduced by the gdb stub?)
<lekernel> in fact, I did that a couple of times already after 'random' freezes, and everytime I got that weird PC
<lekernel> no
<lekernel> it's an old bug I'm just tracking down now using the new gdb tool :)
<mwalle> x/x 0x1f18e2a4 ?
<mwalle> some valid opcode?
<mwalle> mh there was some fmt modifier to decode that instruction, wasnt it?
<mwalle> x/i 0x1f18e2a4
<lekernel> disassemble
<lekernel> mom
<mwalle> looks like a loop ;)
<mwalle> maybe we should enable BUS_ERRORS
<lekernel> bus error?
<mwalle> but then you would have to signal invalid addresses on the WB
<lekernel> you mean generate a bus error when the cpu tries to access an invalid location?
<mwalle> theres some CFG_BUS_ERRORS or sth like that in the lm32 core
<mwalle> which raises an exception
<lekernel> so it would stop the execution as soon as it's crashing... yeah
<lekernel> we should have an "invalid instruction" exception too
<larsc> hm, interesting: gcc/Makefile:TARGET_LIBGCC2_CFLAGS =
<larsc> gcc/Makefile:echo TARGET_LIBGCC2_CFLAGS = '$(TARGET_LIBGCC2_CFLAGS)' >> tmp-libgcc.mvars
<larsc> yet libgcc.mvars contains TARGET_LIBGCC2_CFLAGS = -fPIC
<mwalle> yep, well you would have to have some special exception handling for data and instruction bus errors, too (eg branch to debug rom
<mwalle> larsc: not for me
<mwalle> TARGET_LIBGCC2_CFLAGS =
<larsc> ah. found it
<larsc> well maybe not
<larsc> but i'm using lm32-*-linux instead of -uclinux
<larsc> and there is a t-linux which sets TARGET_LIBGCC2_CFLAGS to -fPIC
<mwalle> larsc: mh there are some other option wich are set if you have *uclinux* triplet iirc
<mwalle> lekernel: mh dunno if thats worth the effort
<lekernel> we'll have to fix those bloody intermittent crashes at some point...
<lekernel> fortunately they do not seem to happen when rendering, only when using the gui
<lekernel> and they're quite rare
<CIA-8> rtems-milkymist: Sebastien Bourdeauducq master * r0c0d5bc / c/src/lib/libbsp/lm32/shared/milkymist_networking/network.c : Ethernet: check received frame CRC - http://bit.ly/ik4VxK
<mwalle> lekernel: whats behind the ra address?
<mwalle> a call?
<mwalle> brb
<lekernel> hm I rebooted
<lekernel> will check next time
<mwalle> if its rom its the content hasnt changed ;)
<mwalle> i would look at my own, but i have a newer rom ;)
<CIA-8> milkymist: Michael Walle master * r02cdac9 / (cores/monitor/rtl/gdbstub.rom software/gdbstub/gdbstub.c): gdbstub: fix max packet size reporting - http://bit.ly/gktZAV
<lekernel> mwalle: thanks
<lekernel> this time crash @ 0x1000029c ...
<mwalle> mh this sounds like the gdbstub was already executing when BREAK was received
<mwalle> larsc: lekernel: i updated my qemu repository. please note that there is no milkymist branch anymore.
<mwalle> only master which is synced with upstream
<larsc> ok
<Fallenou> mwalle: all milkymist stuff is upstream now ?
<mwalle> Fallenou: yes
<mwalle> there are only two missing commits atm, one which stops the vm instead of a cpu_abort and one which fixes debug exception handling
<lekernel> good :)
<lekernel> we should also add support for the higher video resolutions, it didn't work last time i tried (segfault)
<lekernel> should be as simple as reading the hres and vres registers and resizing the window (ignoring the other video timing registers)
<lekernel> i'll have a look at that if you don't before me
<Fallenou> mwalle: ok so I will remove the "checkout the milkymist branch" from the wiki :)
<Fallenou> since all is in master now
<mwalle> Fallenou: yeah
<mwalle> lekernel: theres already some resizing code
<mwalle> if you change hres/vres registers
<lekernel> ha? different bug then... didn't investigate yet... but it appeared when I tried to switch to 1025x768
<lekernel> 1024
<lekernel> #{[{#~! why are the pc->board transfers 16ko/s... with very low lm32 cpu utilization
<mwalle> lekernel: is there a way to get the flickernoise binary out of the fbi file
<mwalle> ?
<lekernel> dd the header off
<mwalle> how long is it?
<lekernel> 8 bytes
<mwalle> i can see any ELF tags in the fbi file
<mwalle> ah because its .ralf
<larsc> mwalle: i still get the same error building qemu
<mwalle> is there a CONFIG_PTIMER in default-configs/lm32-softmmu.mak?
<larsc> yes.
<larsc> i can fix it by prepending the obj file with hw/
<larsc> but then i get the same error for sd.o
<mwalle> do you build in-tree?
<larsc> yes
<mwalle> could you try a out-of-tree build?
<larsc> `make -C qemu-lm32`?
<mwalle> ../qemu/configure --target-list=lm32-softmmu
<mwalle> make
<CIA-8> rtems-milkymist: Sebastien Bourdeauducq master * r14cce88 / c/src/lib/libbsp/lm32/shared/milkymist_networking/network.c : Ethernet: copy-free RX - http://bit.ly/flWS5m
<lekernel> anyone wants my /opt/rtems4.11 with all the flickernoise libs compiled?
<larsc> mwalle: nope, same error
<mwalle> lekernel: yes :)
<mwalle> larsc: grml
<mwalle> whats your configure line?
<lekernel> uploading in http://www.milkymist.org/3rdparty/ ... should be done in ~30min
<lekernel> size 83725495 bytes
<larsc> mwalle: well `../qemu/configure --target-list=lm32-softmmu`
<lekernel> ethernet seems pretty stable now... except that FTP uploads are slow (but downloads aren't)
<lekernel> strange bug..
<mwalle> maybe it'll work for me too ;)
<lekernel> and there are still some rx fifo overflows too :(
<lekernel> even when doubling the on-chip buffering.. if you ping flood with the max packet size, you get a few
<lekernel> (this no longer crashes the board though :)
<lekernel> maybe I could fix that by making the ethernet core DMA to FML
<rofl0r> lekernel, which mtk files specify how stuff is drawn on the screen ? i wanna try to get it to work on directfb
<lekernel> but the problem is the L2 cache should be flushed for retrieving packets then
<lekernel> rofl0r: see fb.c in flickernoise, you just pass MTK a 16bpp framebuffer
<rofl0r> thx
<lekernel> for some reason the board sends duplicate TCP acks and messes up with the TCP window
<lekernel> only for receiving data - board->PC is flawless
<mwalle> lekernel: vgafb resizing should be fixed
<mwalle> larsc: any success?
<larsc> 7nope
<mwalle> really strange
<lekernel> qemu has a profiler?
<lekernel> cool
<lekernel> mwalle: yup, hires works now
<lekernel> thx
<lekernel> sp             0x8cf628c147808908
<lekernel> ra             0xffff0fbf-61505
<lekernel> PC             0xffff35dc-51748
<lekernel> ouch...
<kristianpaul> okay, lets flash finally the MM1 :D
<lekernel> hmm multi-slot RX seems to have fpga bugs
<roh> *laser*
<wolfspraul> lekernel: multi-slot RX?
<lekernel> yes, programming multiple DMA reception buffers into the (softcore) ethernet controller
<lekernel> it seems that when switching quickly to another buffer, some data gets corrupted