<larsc> i don't see how this relocation stuff could have worked
<wpwrak> hmm, looking at things pr-wise, i wonder if making effects react to video and mixing the two already works somewhat. if it does, i think that would yield much more impressive demos than "just" generated effects.
<lekernel_> wpwrak: yeah, mixing the video from the camera has been working for months
<wpwrak> lekernel: (video) also with the effects reacting in some way to the video input ? if yes, that should make for "newsworthy" demos
<lekernel> yes
<lekernel> but I haven't found the occasion to make some good pictures/footage of the system in action
<lekernel> I have some videos, but they are extremely crappy
<wpwrak> lekernel: ah, i see. maybe invite some cute girls over, show them the basics of the system, get them drunk, and just make sure everything gets recorded. drunk girls with cool visual effects. should be a smash on youtube ;-)
<Fallenou> lol
<Fallenou> or a new big title on the news
<wpwrak> Fallenou: both. that's called viral marketing ;-)
<kristianpaul> hmm, i realize now i portant is to use the nanonote as HID device for milkymist
<kristianpaul> had in his bag a mm1, bunch of cables a keyboard,mouse ccd camera and a black cloth
<xiangfu> a black sunglasses :)
<kristianpaul> :p
<kristianpaul> hopefully and autocamtically just when sun light is aorund ;)
<lekernel> kristianpaul: what do you need the nanonote for?
<lekernel> hi xiangfu
<lekernel> how's it going?
<xiangfu> lekernel: hi.
<kristianpaul> lekernel: keyboard
<kristianpaul> man, carry a keyboard is not conforatble
<kristianpaul> well, at least with my keyboard
<lekernel> kristianpaul: I have a rubber rollable keyboard :)
<kristianpaul> i miss it :(
<kristianpaul> mine is broken..
<xiangfu> lekernel: fine. I take two days off. back on working now. full back to work tomorrow :)
<xiangfu> lekernel: I will working on mkyaffs2image in tomorrow I think. hope I can finish it fast.
<lekernel> ok :)
<kristianpaul> xiangfu: did you tried the 1gb card?
<xiangfu> kristianpaul: very sorry. not yet. forget.
<kristianpaul> np
<xiangfu> lekernel: (upload file to /dev/flash5 with ftp) I will test more, write some detail then send one email to list
<lekernel> it also breaks using cp in the shell or the filemanager
<lekernel> try copying a directory hierarchy from memcard to flash, for example
<xiangfu> lekernel: ok.
<lekernel> I guess this has to do with some bug in the eval_path function in the yaffs port
<kristianpaul> i remenber it break for me wittoo :9
<lekernel> you'll see that function is pure crap
<kristianpaul> s/witto/with rm to
<kristianpaul> sorry, latency here is horrible..
<xiangfu> fast test: http://pastebin.com/bxmwjTkk
<xiangfu> cp -R ^
<xiangfu> kristianpaul: `rm` works fine here. never meet an error when do `rm`
<xiangfu> ls
<xiangfu> I have take > 20 screenshot. delete them by `rm` one by one
<kristianpaul> is stuckwith no able to detect memeroy card
<kristianpaul> ...
<xiangfu> same here under memory card.
<lekernel> kristianpaul: so what? put some printf's in the driver... and see where it fails
<lekernel> "not able to detect" isn't going to help
<kristianpaul> lekernel: so what so far i just test on scope
<kristianpaul> i'mnot sure with i think memory card never respond the command sent by cmd line
<lekernel> the scope won't show much... you need at least a logic analyzer
<kristianpaul> yeah.. but out from home now..
<lekernel> but really, using printf() should already help a lot
<kristianpaul> okay
<kristianpaul> the thing is not clear to me, well me be because i dont understand yet it well, the m1testing, failed too..
<kristianpaul> thats why i used, scope, i tought something was not good ther, afaik CLK and CMD seems responsive, so yes i think i'll check software side now.
<lekernel> memory cards, like USB, are super-pesky pieces of trash that require an incredible and extremely frustrating amount of software support to work reliably with all models
<lekernel> we do not have that amount of software support now
<lekernel> so it's not very surprising that it fails at times, and it wouldn't be surprising either that the problems come from software "bugs"
<lekernel> if it's fair to call "bug" a lack of implementation of some crappy detail of that retarded standard
<lekernel> maybe you could try to strip out the existing code and replace that with the Linux or BSD driver code, which dozens of thousands of people helped fix the problems of
<xiangfu> rejon: lekernel do you think ship Milkymist one with a keyboard  is good? the keyboard lekernel just send out"http://www.sizlopedia.com/2007/07/04/5-flexible-rubber-keyboards-for-your-computer/"
<xiangfu> I just search in taobao.com. it's 28RMB in China. just fyi.
<lekernel> don't know... people often have USB keyboard laying around
<lekernel> though 28RMB is cheap indeed
<lekernel> it might also help masking out the intermittent device-dependent USB bugs :) haha
<xiangfu> that is what I thinking. masking usb bug, before we fix that. :)
<rejon> lekernel xiangfu true
<xiangfu> and that is a cool device since we don't need type too much in milkymist one.
<rejon> I had one of those before and I never used it
<rejon> but, its water resistant
<rejon> for rc2 would be good to see
<lekernel> xiangfu: if we ship that keyboard, I guess we're going to need localized layouts
<lekernel> azerty, qwerty, etc.
<lekernel> can you find all of them for ~28 rmb?
<xiangfu> lekernel: hmm.. not sure. but we can ask Yi to find out.
<lekernel> btw, if you're fed up with the rtems filesystem and want an easy task to relax a bit, you can implement other keyboard layouts in MTK :)
<rejon> ha
<rejon> the new camera wolfie found is great btw
<rejon> lekernel I found some new music in sf that fits milkymist real well
<rejon> chillwave
<rejon> kind of raw
<rejon> hipster music
<lekernel> yeah, why not :)
<rejon> yeah, it was pretty raw, but loads of ladies
<lekernel> actually i've successfully used it on both german electro and oriental acoustic
<rejon> excellent
<lekernel> very different styles, both were good :)
<rejon> will record more footage of use
<lekernel> I should get some footage too... I have some of that oriental thing but the picture quality is so crappy it's unusable
<rejon> synth music
<rejon> one thing super useful for mm1
<rejon> or rather flickernoise
<rejon> is transitions between patches
<rejon> since without two vga, in dark
<rejon> maybe this exists
<rejon> some type of basic sequencer
<lekernel> yes... you can map that to the keyboard, to MIDI, OSC, remote control, ...
<rejon> excellent
<rejon> http://barrythrew.com has mind for a few days...he playing with, taking by his company
<rejon> I showed to my buddy http://christopherwillits.com too
<lekernel> when you map it to MIDI keyboard it's pretty cool. you can switch very fast between the patches (the software has zero delay for switching) and "play" it like a piano
<rejon> he  writes for xl8r and has personal ppl at these mags
<rejon> music mags
<lekernel> make sure you show them the latest video-in enabled patches
<lekernel> some need DMX, if you do not have a DMX controller around you should modify the patch code a bit
<rejon> so whta most of these dudes in sf are using now
<rejon> is touchdesigner on a pc
<rejon> and an ipad with osc to control the video
<rejon> so not far off
<rejon> from us
<rejon> would be interesting to have adaptable tablet as a controller for milkymist
<lekernel> i was actually thinking about making milkymist a tablet. but for way later :)
<rejon> yeah
<lekernel> btw we support OSC already and that ipad controller should work
<rejon> excellent
<rejon> that is a good feature
<rejon> to note
<rejon> most of these people don't give a shit about open
<lekernel> actually you could drop-in replace the DMX with OSC in the video patches I pointed you to
<lekernel> and use that ipad to control
<rejon> excellent
<rejon> lekernel wonder how we could get that milkytab working well
<rejon> is there similar android OSC controls?
<lekernel> later
<lekernel> it won't happen anytime soon
<rejon> could get up and running on nook quick and easy
<rejon> i know
<rejon> i'm talking android
<rejon> and nook
<rejon> just a thought, but not distraction
<lekernel> if you have an OSC controller running on android, yeah, it should work
<lekernel> flickernoise uses liblo for decoding OSC, which has been successfully used by many other PC applications
<rejon> aha
<rejon> supercollider is another tool that would be useful for this audio scene
<rejon> barry from fabricatorz is also max/msp/pd developer
<lekernel> oh yeah, there are tons of stuff for OSC
<rejon> that is great
<CIA-43> milkymist: Michael Walle master * rf265ea1 / (cores/sysctl/rtl/sysctl.v software/include/hw/sysctl.h):
<CIA-43> milkymist: add a debug scrachpad register to sysctl
<CIA-43> milkymist: This register is required by the GDB stub. - http://bit.ly/f0rGOp
<CIA-43> milkymist: Michael Walle master * rc1cedde / (cores/uart/rtl/uart.v software/include/hw/uart.h): uart: add a tx pending status bit - http://bit.ly/gizTB6
<CIA-43> milkymist: Michael Walle master * rb925cc8 / boards/milkymist-one/rtl/system.v : add UART BREAK support to the SoC - http://bit.ly/egWX9b
<CIA-43> milkymist: Michael Walle master * r76fe4d4 / (cores/lm32/rtl/lm32_cpu.v cores/lm32/rtl/lm32_top.v):
<CIA-43> milkymist: lm32: add support for an external break pulse
<CIA-43> milkymist: Pulsing this input generates a breakpoint exception. - http://bit.ly/gpwnlH
<lekernel> rejon: you should put up shows with your friends :)
<rejon> of course!
<rejon> you should come to lgm!
<rejon> we doing events every night
<rejon> all day free software creative app developers
<rejon> and designers presenting
<rejon> i buy milkymist one, i promote you guys, but yet you and wolfgang won't come to my conference...its scandalous!
<larsc> hm... it is on the wrong side of canada
<lekernel> 14 hr flight from Berlin :(
<lekernel> tbh i'd have come if it were in Brussels like last year
<rejon> will pay for your flight even
<rejon> ;)
<larsc> i'm vancouver during that time. it would is still a 2 days carride though
<rejon> 3 hour flight
<rejon> rockstar it!
<rejon> oops, wrongwindow
<lekernel> rejon: what's the deadline again? apr 20?
<rejon> yeah
<rejon> or sooner :)
<rejon> plus there are all those mutek people there and friends from ninjatune
<rejon> etc
<roh> mutek? where?
<rejon> in montreal
<roh> meh
<rejon> you are too good for it?
<roh> nah. but its too far away
<lekernel> rejon: being stuck in transports for 28 hours is something I hate personally, and it's not a matter of being too good for the event or any other participant. it's a matter of whether it's going to help the project enough to be worth the hassle, which isn't the same thing.
<roh> i'd like airtravel if i could use a learjet ;)
<rejon> its good if you make it good
<rejon> not everything free and easy
<rejon> sometimes have to help others out too
<lekernel> lol... they broke LM32 GCC _again_ just before the 4.6 release
<lekernel> before we have llvm maybe the way to go is to maintain a 4.4 version, which to my knowledge is the less shitty (and the only one with which c++ appears to work)
<kristianpaul> well if 4.4 worked well i dont see why use earlier version, at least if you need features for rtems, wich i dont think so
<mw1> btw milkymist support is qemu upstream
<Fallenou> awesome !
<mw1> unfortunately there may be a regression
<lekernel> huh? weird...
<mw1> esp SIGUSR2 ?!
<methril_work> lekernel, now i understand why i get stuck compiling 4.6
<methril_work> blames cc1 infinite loop and memory hungry
<lekernel> you get this too?
<methril_work> lekernel, nop, diferent one
<methril_work> i was looking for a solution, but it`s a little bit try & error
<lekernel> when I checked, it built correctly with --enable-languages=c
<methril_work> i`ll try with that, but it could be my libraries (mpfr & mpc
<methril_work> )
<mwalle> mh qemu sends SIGUSR2 at some point
<lekernel> methril_work: ok i'm trying to build gcc head atm
<lekernel> with ../gcc/configure --target=lm32-rtems4.11 --prefix=/opt/rtems-4.11 --enable-languages="c"
<lekernel> btw that thing supposedly supports google go
<lekernel> i'll give it a try if that C compiler builds
<lekernel> ah, yeah, that damned C compiler was indeed broken since my last test
<lekernel> it's a new bug
<lekernel> now I understand why GCC status reports seem to put forward "regressions" and not "new features"
<lekernel> krkr
<lekernel> huh... I don't get it
<lekernel> the very same code that used to build now suffers from the cc1 segfault
<lekernel> could that be related to some system library... wtf
<lekernel> ok, fuck it i'm fed up with gcc
<lekernel> use 4.4, period
<lekernel> meanwhile i'll ping those guys who talked about llvm
<methril_work> lekernel, for me it was not a segfault, it starts to get more and more memory,and almost all my cpu
<methril_work> in conftest.c
<lekernel> funny...
<methril_work> this is the hardest part to find, just cause cc1 is intermediate compiled :(
<lekernel> anything gcc is hard. the code is such a mess
<methril_work> i remember to deal with a bug like that....
<methril_work> it was a missing lib dependency
<methril_work> btw, you love GCC when you have to deal with compilers like SDCC or undocumented MSVC or C18
<lekernel> sdcc is just plain crap man
<lekernel> don't even dare call that a compiler
<mwalle> pcc ?
<mwalle> just reached 1.0 after 30 years :)
<lekernel> yeah... there was a long empty period it seems
<methril_work> lekernel, it`s the best opensource compiler for pic devices
<lekernel> I have never tried pcc
<methril_work> neither do i
<lekernel> I have used SDCC to reprogram the 8051 firmware of a DSL modem that I wanted to turn into a SDR. SDCC is part of the reasons why I never completed this project.
<lekernel> if you want to continue, it was with the AD Eagle chips
<lekernel> which are a Cypress fx-usb + AD DSP in the same package
<methril_work> lekernel, i use SDCC for my daily/paid work
<lekernel> all undocumented ofc
<methril_work> well, the undocumented is the challenge ;)
<lekernel> sdcc problems too
<methril_work> i see sdcc has improved (a little bit) but is a really slow progress
<methril_work> what version did you use?
<lekernel> don't remember... it was in 2005
<lekernel> the (proprietary) DSP toolchain was quite messy too
<methril_work> well, they are still improving the 8051 arch, and is the maturest of the archs
<methril_work> all this is why i love milkymist ;)
<mwalle> whats a SDR?
<mwalle> software defined radio?
<lekernel> yes
<lekernel> some DSL modems have rather interesting DSPs for this purpose, and can be fully reprogrammed over USB
<lekernel> (and they're dirt cheap)
<roh> vdsl modems do 30mhz spectrum
<methril_work> uhm!! it could be used as a DSL/ATM sniffer/decoder
<lekernel> yup. but given my limited interest in security and the greater difficulty compared to SDR, that's not what I planned to do :p
<lekernel> mwalle: what do we do with the JTAG ROM? toss?
<mwalle> now the flterm gdb passthrough patch is still missing, for some reason poll() wont block if gdb releases the pseudo terminal..
<lekernel> keep both? (jtag+serial)
<lekernel> we can keep both and select one with the LM32 config?
<mwalle> lekernel: i would keep both
<lekernel> maybe have one enabled by default in the SoC
<lekernel> I guess the serial one works better?
<mwalle> see CFG_GDBSTUB_ENABLED
<lekernel> yup
<mwalle> well both are working, but there is no working frontend for the jtag one
<mwalle> i dont know the status of terpstra_'s jtag interface
<Fallenou> lekernel: strange there was no ioctl to change the resolution ?
<mwalle> btw i guess JTAG break wont work if there is an interrupt at the same time, in which case only the interrupt exception is raised
<Fallenou> even FBIOPUT_VSCREENINFO ?
<lekernel> hmm... in fact, maybe
<lekernel> checking
<mwalle> lekernel: did you looked into the new lm32 version?
<lekernel> which one? the nov 2010 lscc release?
<mwalle> yes
<lekernel> iirc there wasn't much (if anything) changed
<Fallenou> you can put the switching of mode in the FBIOPUT_VSCREENINFO which is aimed at changing the value of the fb_var_screeninfo containing the xres and yres
<Fallenou> dunno if it would be clean
<mwalle> terpstra_: btw your jtag patches are still on my queue, i haven't forgot it
<lekernel> Fallenou: maybe. otoh i won't go to great lengths just to get 3 different video modes switched.
<lekernel> I'm afraid the regular framebuffer api for switching modes might be rather complex...
<larsc> FBIOPUT_VSCREENINFO is the right method
<Fallenou> lekernel: I was just thinking you can just use this already existing ioctl, call your set_video_mode() and change the internal structure and that's all
<Fallenou> it would avoid adding one new ioctl
<mwalle> gn8
<CIA-43> mtk: Sebastien Bourdeauducq master * r18dc912 / (include/mtklib.h lib/main.c lib/screen.c): Support changing screen resolution while running - http://bit.ly/hCMcru
<CIA-43> flickernoise: Sebastien Bourdeauducq master * r8c2f9e4 / (6 files): Dynamic video mode switching - http://bit.ly/eG2nWd
<CIA-43> mtk: Sebastien Bourdeauducq master * r5e39a17 / lib/main.c : cleanup - http://bit.ly/eNlKln
<lekernel> he, now wireshark shows "QiHardwa" MACs :)
<CIA-43> flickernoise: Sebastien Bourdeauducq master * r9db3757 / src/performance.c : missing include - http://bit.ly/gQPnYb
<CIA-43> milkymist: Michael Walle master * ra86d6b8 / (4 files):
<CIA-43> milkymist: gdbstub: initial import
<CIA-43> milkymist: This patch adds a gdb stub which replaces the tiny LM32 debug monitor. It
<CIA-43> milkymist: needs some more resources but has the advantage that you can directly
<CIA-43> milkymist: connect with GDB. - http://bit.ly/gk1efy
<CIA-43> milkymist: Michael Walle master * r7f89158 / (3 files in 2 dirs): monitor: add gdbstub ROM - http://bit.ly/fmgnRJ
<CIA-43> milkymist: Michael Walle master * r279047a / boards/milkymist-one/rtl/lm32_include.v : system: enable gdb stub and breakpoints - http://bit.ly/fs1jSw
<lekernel> boot time from power button press is 9s without wallpaper and 15s with a 1024x768 24bpp floyd steinberg dithered PNG
<lekernel> for some reason libpng is slow as crap
<lekernel> maybe libjpeg is better?
<Fallenou> 00:31 < lekernel> he, now wireshark shows "QiHardwa" MACs :) < haha nice :))
<lekernel> argh... after mwalle's patches, ise fails timing with normal bitstream but works with rescue one
<Fallenou> libbmp would surely be faster ;)
<Fallenou> lekernel: what is the big diff between normal and rescue bitstream ?
<lekernel> yeah, why not
<lekernel> Fallenou: just the CPU reset vector value
<lekernel> there is no big difference
<Fallenou> ok
<Fallenou> the reset vector are in the hdl ? :o
<lekernel> but p&r tools are stochastic
<lekernel> at least, the fpga ones. it seems in the asic world they have developed better ones, but the fpga companies didn't catch up yet
<lekernel> when i have 180-hour days i'll implement those in antares
<Fallenou> lol
<lekernel> I get some warnings but it seems to work
<lekernel> Ignoring packet error, continuing...
<lekernel> warning: unrecognized item "Packett" in "qSupported" response
<lekernel> it's very slow, too
<lekernel> even though it's not continuously transmitting data, so it looks more like a bug than normal rs232 slowness
<Fallenou> seems to work, isn't it ?
<lekernel> partly
<lekernel> I just tried "step" and it locked up
<lekernel> I get lots of "packet errors", maybe it's just that my serial link is corrupted somehow
<Fallenou> is step using a breakpoint to work ?
<Fallenou> on the pic, they are using a breakpoint to do the "next step"
<Fallenou> so if you put the maximum number of breakpoints authorized
<Fallenou> you cannot step
<Fallenou> cause you've used all the breakpoint available :)
<Fallenou> (and it's like 4 or 5)
<lekernel> I didn't use any breakpoint, and just one step
<lekernel> "where" seems to work, which is already a good thing to find out more about those irritating random intermittent system lockups