#milkymist IRC log for Monday, 2011-03-28

lekernelwhat's the difference between "line out" and "line level out"?00:37
lekernelthe wm codec has both00:37
lekernelatm we're using the "line out" and it works, so i guess we'll stick with that00:37
lekernelhi aw00:38
lekernelcould you get samples of WM9707? we'll probably use it in the end00:40
awlekernel, hi evening00:40
awyes, i can order some of them.00:41
awstill reading your email. :-)00:41
lekernelyeah... you should read the IRC log too :)00:42
awokay...i may change some capacitor with low ESR to have extremely lower ripples from power supplies to check.00:43
lekernelyou think the noise might come from power supply caps?00:45
lekernelFYI: I'm using the WM codec without noise now00:45
lekernelI have fixed some problems in the FPGA design that prevented it from working correctly00:45
lekerneland now we have noise free audio00:45
awyes, WM may have different performance noise reduction tech...yup? also fixed on fpga design?>>> sounds great.00:46
awyou used WM codec in RC1 not RC2, right?00:50
rohaw: ack. it was a fight!00:51
rohnot for the wm.. that one came out easy... the video adc was hard00:51
rohi either need nozzles for that tqfp stuff or much more experience ;)00:52
rohaw: can you tell us about your hot-air experiences, give some tips?00:53
awroh, yup, such skilled tech. you have is great. :-)00:53
lekernelyeah, I took a RC1 board00:54
awwell...last week i just used hot-air to rescue one damaged RC2 board with all ICs,00:54
lekernelroh: well, with the bigger nozzle it wasn't so hard00:54
lekerneland leaded solder doesn't have so much tendency of forming balls behind the pins00:55
awlekernel, okay..the layout/schematic between rc1 and rc2 is quite different, so i may yes order WM to replace it on my rc2 for confirmation.00:55
lekernelaw: the WM chip requires a few modifications00:56
awlekernel, yup, can imagine. :-)00:56
lekernelremove 1M resistor on crystal, add capacitor on pin 33 (for 3D effect, optional), add capacitors on pin 3200:56
lekernelI have uploaded the datasheet to the git repos. please have a look at it00:57
lekernel_<lekernel> remove 1M resistor on crystal, add capacitor on pin 33 (for 3D effect, optional), add capacitors on pin 3201:00
lekernel_ I have uploaded the datasheet to the git repos. please have a look at it01:00
lekernel_ also, we might also want to route SPDIF to the internal connector and DNP the parts for the nonexistent headphones amp01:00
lekernel_you should also recompile the test program01:01
awlekernel_, um..seems lot of works to be learn on my side. ;-)01:06
lekernel_btw i'm running the demo console in 800x600 resolution atm01:14
awhas this changed by SoC or s/w porting enough?01:15
lekernel_some dirty soc hacks01:17
lekernel_1024*768 wouldn't work though. well, maybe with more buffering01:19
awlekernel_, do you think that we still need U23 if change into WM in the end? or not necessary.01:21
lekernel_the 4.3V regulator?01:22
lekernel_well... could be a good idea to protect against incoming power supply noise01:22
lekernel_at least we have more safety if we happen to pick up a noisy transformer01:23
awI probably also order some low ESR capacitors to replace C215 10uF. As a recommended part there in datasheet. ;-) yeap, seems use it as a seperated circuitry part.01:25
awi saw some doc the 'white' noise can come from bad ripples from power supply, but we didn't test though. :-)01:28
lekernel_power supply?01:31
lekernel_I checked it on scope... looks clean01:31
lekernel_but you can still double check :)01:31
awyeah, double check is good after replace a low ESR capacitor. :-)01:32
xiangfulekernel_: Hi. I am working on try to create the /dev/flash5 image.  then ender user can easy flash that by using urJtag. got more patches and wallpaper.png02:06
xiangfulekernel_: I think I mis-understand your task about default wallpaper.02:06
xiangfuso I talk with wolfgang about my task on milkymist one.02:06
xiangfusomething wrong with the "www.milkymist.org"?  always give me connect timeout. and06:24
xiangfu--- www.milkymist.org ping statistics ---06:24
xiangfu11 packets transmitted, 0 received, 100% packet loss, time 9999ms06:24
xiangfuxiangfu@fidelio:~$ ping www.milkymist.org06:25
xiangfuPING www.milkymist.org ( 56(84) bytes of data.06:25
xiangfu--- www.milkymist.org ping statistics ---06:25
xiangfu11 packets transmitted, 0 received, 100% packet loss, time 9999ms06:25
rejonxiangfu might be our location06:30
rohrejon: i can't reach it either. seems down06:30
xiangfurejon: I tried in qi-hardware.com. in Germany  :)06:31
rejoni got sweet vpn running here now at mozilla china office06:31
xiangfuww.milkymist.org works fine now07:02
awi also can't reach taipei here 1 hour ago, but now it's ok.07:03
xiangfuhow can I copy file from milkymist one to PC?07:28
xiangfuI try the tftp. it's always give me timeout.07:28
xiangfugot it. it's ftp.07:37
xiangfumy first 'fbgrab' in milkymist one : http://downloads.qi-hardware.com/people/xiangfu/tmp/mm1.c.png08:11
xiangfukristianpaul: wolfspraul. the 'fbgrab' is working :) http://downloads.qi-hardware.com/people/xiangfu/tmp/mm1.2.png10:06
kristianpaulxiangfu: ohhh10:09
kristianpaulxiangfu: cheers !10:10
xiangfukristianpaul: I shoudl connect the camera to which color of video in?10:11
Fallenouwell done xiangfu :) thanks !10:13
xiangfukristianpaul: http://downloads.qi-hardware.com/people/xiangfu/tmp/mm1.video.in.1.png10:25
xiangfuthis may help find out the video issue.10:26
xiangfuFallenou: now. I try to send patch to lekernel :)10:27
kristianpaulxiangfu: green i remenber10:46
kristianpaulnice car ;)10:46
xiangfunot in my yard. only in my camera :D10:47
lekernel_xiangfu: nice shots10:47
lekernel_i'll replace that on milkymist.org10:47
lekernel_if you don't mind :)10:47
xiangfulekernel_: sure.10:47
kristianpaulwoah, thats cool http://downloads.qi-hardware.com/people/xiangfu/tmp/mm1.4.png10:57
xiangfuI like this patch very much, thanks lekernel.   :)11:00
kristianpaulwhat's the name of this one?11:01
kristianpaullooks awesome indeed11:01
Fallenouxiangfu: oh you have screenshot feature even in performance mode ?11:02
xiangfuFallenou: yes. when run 'fbgrab' the performance will stop.11:03
xiangfuI guess it's cause real time os. right?11:03
Fallenouhow do I run it ? typing "fbgrab" in the rtems shell ?11:03
xiangfufbgrab file_name.png11:03
Fallenouin the shell ?11:03
Fallenoustrange that it stops the performance11:04
xiangfuoh. it's stop everything.11:04
xiangfufor example. connect with telnet. ftp. and serial11:04
Fallenouyou mean it freezes the board ? :o11:04
Fallenouand then after the screenshot, everything resumes ?11:05
xiangfuwhen you do 'fbgrab' in serial. the 'telnet' and 'ftp' just stop. until 'fbgrab' finish.11:05
xiangfuFallenou: yes.11:05
Fallenouoooh ok11:05
wolfspraulxiangfu: wow nice - congrats!11:05
xiangfuFallenou: this is not normal?11:05
Fallenouit should not11:05
Fallenouftp and shell should run in separate threads11:06
wolfspraulnow we need to be able to do the fbgrab from a (usb) keypress11:06
xiangfuthe fbgrab need ~16 seconds.11:06
Fallenourtems runs several threads11:06
Fallenouand do scheduling among them11:06
wolfsprauland we need to publish flickernoise images that have this included (and get the patches accepted upstream by sebastien)11:06
wolfspraul16 seconds? :-)11:06
wolfspraulthat's the next thing to optimize :-)11:06
Fallenou16 seconds to read a 640x480 array ?11:06
wolfspraulbut one by one, it's great progress, very good!11:07
xiangfuFallenou: I using the 'time fbgrab a.png'11:07
xiangfuFallenou: let me run that again.11:07
Fallenounever tested the time in rtems shell11:07
xiangfuFallenou: I think because write nor flash.11:08
xiangfuI tried copy files from memory card to /dev/flash5. very very slow.11:09
Fallenouoooh yes maybe11:09
Fallenoutry to write to the ramfs11:09
Fallenoujust to see the speedup you get11:09
Fallenouit might give you the "incompressible" part of the time11:09
Fallenouto show you what you can optimize and what you cannot11:09
Fallenou(ramfs is mounted on /ramdisk )11:10
FallenouI don't know how much ram is mounted there, maybe some 4 kB11:10
xiangfu[/flash] # time fbgrab 7.png11:11
xiangfu11: time fbgrab 7.png11:11
xiangfuConverting image from 1611:11
xiangfuNow writing PNG file...11:11
xiangfutime: 0:02:28.67011:11
xiangfuunder flash. I start the performance, ftp, and telnet. some music played in line-in.11:12
Fallenoutry to write in /ramdisk (if there is enough space) or just try commenting out the part that actually write)11:12
xiangfuthe music not stop.11:12
xiangfuFallenou: ok.11:13
Fallenoujust to confirm the write is the big part11:13
Fallenouwhich may be incompressible unfortunately :/11:13
lekernel_xiangfu: seems you don't close /dev/fb in your fbgrab function11:14
lekernel_and the fact that the software freezes while fbgrab is running is perfectly normal11:14
xiangfulekernel_: oh. yes.11:14
xiangfulekernel_: too bad. :(11:15
lekernel_fbgrab is running with the shell task priority, which is the highest11:15
Fallenouoh ok so it's a priority thing11:15
lekernel_so RTEMS will not preempt it as long as it has something to do11:15
lekernel_if you want to put it in the background, you could spawn a PNG compress/write sub-task11:15
lekernel_with low priority11:15
lekernel_also be careful if you read the framebuffer in this subtask11:15
lekernel_because it can be modified by other tasks while you read it :)11:16
xiangfu(subtask) don't know how to do that now. :( need look into document.11:16
xiangfuwolfspraul: (keyboard shotcut) yes.11:17
lekernel_so the dirty solution is to take a copy of the framebuffer in a high priority task and then process it in a low priority task11:17
xiangfukristianpaul: it's "Lekernel - Vibrant Plasma Streams.fnp"11:17
lekernel_a clean solution can be copy-free (since the framebuffer is already mapped in memory and uses triple buffering) and you'd simply "lock" the current displayed framebuffer from the driver11:18
lekernel_i.e. you add a 4th buffer11:18
lekernel_in normal operation, that 4th buffer isn't used, it's the current triple buffering11:19
lekernel_but when fbgrab requests a still framebuffer you return the currently displayed one and you don't touch it again until fbgrab is done with it11:19
lekernel_but you can keep rendering using the other 3 remaining buffers11:19
lekernel_it's a bit more complex to implement, but it would make fbgrab not interfere at all with the rendering11:20
lekernel_also, keep in mind that the CPU is heavily used by the rendering already11:21
lekernel_so if you use a background task, your PNG encoding can take forever11:21
lekernel_about the ramdisk: you can write loads of stuff there, it's allocating on the ~100MB heap11:22
wolfspraulxiangfu - my m1 still has flickernoise 0.1 - what is the easiest way to upgrade?11:26
xiangfulekernel_: thanks for the info.11:27
xiangfuwolfspraul: urjtag. I think.11:27
wolfspraulok. need to disassemble my case first then...11:28
xiangfuwolfspraul: or this one: http://lekernel.net/blog/?p=133911:29
wolfsprauland find one of those small allen keys for it, argh...11:29
xiangfubut I never tried this method.11:29
wolfspraulwhich one do you use?11:29
xiangfuback online in 1 hours.11:30
CIA-43milkymist: Sebastien Bourdeauducq master * r99b1cfe / software/bios/Makefile : remove duplicate code in makefile (Xiangfu) - http://bit.ly/e5RwfR11:49
lekernel_got 1024x768 ...with still some bugs though12:39
wolfspraulhey my projector can only do 800x60012:43
wolfsprauland I bought it because I thought it was 'future-proof' with m1. but you seem to be too fast!12:43
wolfspraulmy flickernoise 0.1 does not work with an Apple USB keyboad I have here12:44
lekernel_is that a keyboard with integrated hub?12:44
wolfspraulis that something that was improved in later flickernoises?12:44
wolfspraulwait, checking...12:44
wolfspraulyes, indeed12:45
wolfspraulwhen I plug it into LInux, I get 2 new devices, hub and keyboard12:45
lekernel_keyboards with integrated hubs are fucking extreme bloody pains in the ass that would make you hate USB forever should you even think about trying to develop support for them12:45
wolfspraulgood catch!12:45
wolfspraulwell, xiangfu can add it to his todo list :-)12:45
lekernel_and they're not supported atm12:45
wolfspraul(at the bottom though)12:45
lekernel_well it won't be an easy task12:45
wolfspraulno problem, I will find another keyboard12:45
wolfspraulyes I can imagine12:45
wolfspraulnot the right priority now12:45
wolfspraulI will find another keyboard12:45
wolfspraulthen I much rather have xiangfu implement usb keyboard support in the Ben NanoNote :-)12:46
wolfspraulwithout a hub, of course12:46
wolfspraulthanks that was an easy catch. I will find another keyboard.12:46
lekernel_god, USB is so stupid... how could one even dream about making so complicated and messy the simple task of transmitting key presses and mouse moves down a bit of electric wire?12:48
lekernel_I don't get it12:48
xiangfubtw. I have a wireless mouse and keyboard.   using one usb receiver. the mouse works fine. keyboard not working12:48
lekernel_xiangfu: also you're not freeing buf_p in fbgrab12:52
lekernel_and zeroing it should be unnecessary12:52
lekernel_you could also use an ioctl() interface that gives you the address of the framebuffer... and you wouldn't have to allocate memory anymore12:53
xiangfulekernel_: thanks.12:55
Fallenouaccessing the fb through the driver each time is an overhead12:56
Fallenouaccessing directly the memory array is faster12:56
xiangfuis that ok, just read the framebuffer when mm1 do performance ?12:56
Fallenoulook at how it is done in fb.c12:57
Fallenou(for the ioctl)12:57
lekernel_wolfspraul: for the resolution, 800x600 will be supported as well. ideally, we could even detect the supported resolutions with DDC and pick the highest.13:00
lekernel_and in fact it wouldn't make much difference with the rendering, only with the GUI13:00
lekernel_I don't believe the current SoC architecture would be able to run the complete rendering system at high resolutions and high frame rate13:00
lekernel_so the rendering would happen with a limited resolution internal framebuffer that is scaled up on the fly by the VGA controller13:01
xiangfulekernel_: I will send another patch with fixed 'free' and 'close', I will look into the ioctl, direct read framebuffer.13:06
xiangfulekernel_: I add the close(fd) to the end of main_fbgrab. the problem.13:12
xiangfueverytime 'fbgrab a.png' finished the screen got no signal.13:12
lekernel_ah :)13:13
lekernel_uhm, yes13:13
xiangfujust like the close(fd), close the vga output.13:13
lekernel_actually the framebuffer driver isn't supposed to be acceded from two different tasks13:13
lekernel_it enables video out at open() and disables it at close()13:13
lekernel_you should be able to fix that by adding a reference counter to it13:14
xiangfuyes. when I run the fbgrab again. video out work again. before fbgrab finished.13:14
lekernel_do you see how?13:14
lekernel_open: ref_counter++; if(ref_counter == 1) enable_video();13:15
lekernel_close: ref_counter--; if(ref_counter == 0) disable_video();13:15
xiangfuin c/src/lib/libbsp/lm32/shared/milkymist_framebuffer/framebuffer.c right?13:16
lekernel_and with mutexes if you want something neat13:16
xiangfulekernel_: I will try to do that.13:17
xiangfucounter first :)13:17
lekernel_1024x768 working bug free now :)13:19
xiangfuso I can also get the resolution by using ioctl ?13:19
lekernel_but it collapses when you start rendering13:19
lekernel_the memory can't keep up13:19
lekernel_we'll definitely need scaling13:19
lekernel_hm, don't know. haven't looked at how to implement that in RTEMS yet13:20
lekernel_but when it's done yes, it'll be with ioctl()13:20
xiangfu(scaling) under verilog code right? (I try to understand more)13:20
lekernel_yes, when rendering the FPGA will scale the low resolution framebuffer on the fly, at the same time as it generates the video signal13:21
lekernel_this way the load on the memory system is only that of the low resolution framebuffer13:21
lekernel_but when using the GUI, the needed memory bandwidth is much lower, and we can enjoy the full resolution13:21
lekernel_he 14 fps @ 1024x76813:26
lekernel_it's not that bad13:26
lekernel_(i'm using the demo firmware now)13:29
xiangfulekernel_: http://pastebin.com/E1cVn3WW. is this ok?13:30
xiangfuref_counter ^13:30
lekernel_yeah, looks good13:30
xiangfulekernel_: ok. I will send out the patch to mailing list.13:31
Fallenouthe resolution is held in a struct fb_var_screeninfo13:32
Fallenoudunno if you can get it from ioctl13:32
Fallenoui guess not :x13:32
Fallenouxiangfu:  FBIOGET_VSCREENINFO13:34
Fallenouthis ioctl will give you the good struct :)13:34
Fallenouto get the resolution13:34
xiangfuFallenou: ok. try to implement in next fbgrab. 1. direct read fb; 2. get more info by using ioctl13:35
xiangfuFallenou: thanks.13:35
lekernel_ok, now the funny part: use partial reconfiguration to let the software change the pixel clock13:37
lekernel_since it seems xilinx fucked up the normal way to reconfigure clock generators, I guess I'll have to spend the afternoon doing icky fpga hacking13:38
Fallenoulekernel_: will the rtems framebuffer driver have to change its resolution?13:40
lekernel_hmm... I guess I'll generate a differential bitstream with only the DCM configuration changed and then throw that into the ICAP to change the pixel clock13:41
FallenouI mean dinamically13:41
lekernel_yes, sure. we want GUI menus to select the resolution, don't we?13:41
lekernel_and before on the fly scaling works, we might even have to switch back to 640x480 during rendering13:41
Fallenouok so we need to implement the FBIOPUT_VSCREENINFO13:42
xiangfulekernel_: I have a very small patch to connect mm1 by serial console. but not sure if you would like put it in milkymist.git or flickernoise.git. blow is the small patch13:44
xiangfu+connect: /dev/ttyUSB113:44
xiangfu+       stty -F $< raw 11520013:44
xiangfu+       while : ; do cat $< ; done & cat > $<13:44
xiangfui add it to "milkymist.git/boards/milkymist-one/flash/Makefile"13:44
xiangfulekernel_: http://pastebin.com/UTgAwWcG. this one is more clear13:46
lekernel_why not use flterm?13:46
lekernel_or gtkterm, or...? :)13:46
xiangfuah. I always using 'kermit' :).13:47
xiangfuthis one is just for ender using maybe.13:47
xiangfulekernel_: a better one. : http://pastebin.com/pgiznE7u13:48
xiangfuI would like this small feature. since some one just bought on mm1. then he connect the usb cable. run 'make connect' he can got the boot log :)13:49
CIA-43milkymist: Sebastien Bourdeauducq master * rdcef87c / boards/milkymist-one/flash/Makefile : flash: connect target to get boot log (Xiangfu) - http://bit.ly/geWVza13:53
xiangfulekernel_: thanks. :)13:54
xiangfulekernel_: sorry. the my terminal make the 'tab' as 'space'. :(14:01
lekernel_and what's the problem?14:02
xiangfulekernel_: after you apply my patch from "http://pastebin.com/pgiznE7u" in makefile the front of 'stty ...' and 'while ..' is space not 'tab'14:04
lekernel_ah, and it should be a phony target too14:05
CIA-43milkymist: Sebastien Bourdeauducq master * recb9635 / boards/milkymist-one/flash/Makefile : fix connect target - http://bit.ly/g2iX5Z14:06
xiangfunew patches send out. one for rtems-milkymist.git the fb ref counter. another is fbgrab fixed. free and close.14:10
lekernel_I put your screenshots online: http://www.milkymist.org/flickernoise.html14:11
lekernel_thanks for those!14:11
lekernel_we should put some with the video input14:11
lekernel_preferably with good looking dancers etc. :)14:11
kristianpauli can find good looking dancers next week at labsurlab ;-)14:15
xiangfuafter I update the rtems-milkymist.git. I got some error on network.14:16
xiangfu"No rx buffers left in the pool! We are in big troubles!"14:17
xiangfuok. not always. after reboot. the ftp works fine again14:17
lekernel_yeah, there are still several ethernet bugs14:18
CIA-43rtems-milkymist: Sebastien Bourdeauducq master * r68f1136 / c/src/lib/libbsp/lm32/shared/milkymist_framebuffer/framebuffer.c : add open ref_counter to framebuffer driver (Xiangfu) - http://bit.ly/gAoF3v15:09
lekernel_xiangfu: could you re-send your fbgrab patch with tabs for indentation?15:16
Fallenouhum I've read somewhere that usually spaces are preferred15:22
Fallenoubecause tabs can be interpreted by your editor15:22
xiangfulekernel: sended out. will more carefully next time.15:22
xiangfuFallenou: linux kernel style is using 'tab'15:23
Fallenoutabs could show up as a different number of spaces depending on the editor15:23
Fallenouwhereas spaces are always the same15:23
Fallenouxiangfu: so I guess it's the best :p15:24
xiangfulekernel: btw. I saw you always manually apply the patch. I always using save the file to .eml, the 'git am PATCH_EMAIL.eml', if the patch is as expect :)15:26
xiangfuFallenou: the only issue for me is the terminal always replace 'tab' with 'spaces'.15:30
CIA-43flickernoise: Xiangfu Liu master * r64ea9ad / (src/main.c src/shellext.c src/shellext.h):15:31
CIA-43flickernoise: add screenshot command fbgrab15:31
CIA-43flickernoise:  add screenshot command fbgrab15:31
CIA-43flickernoise:  add topic 'flickernoise'15:31
CIA-43flickernoise: TODO:15:31
CIA-43flickernoise:  * direct read fb memory15:31
CIA-43flickernoise:  * get more info by using ioctl - http://bit.ly/i4YvHS15:31
lekernelxiangfu: thanks15:31
lekerneland tab width is 815:32
lekernel(to answer Fallenou's concern :p)15:32
Fallenouwell if you say you want real tabs15:33
Fallenouthere is no width :o15:33
Fallenouthe width is the way the editor displays it15:33
xiangfutime for sleep. see you.15:35
Fallenougn8 !15:35
CIA-43milkymist: Sebastien Bourdeauducq master * re758b81 / software/libhal/snd.c : demo: display WM9707 codec when found - http://bit.ly/hT1vau15:42
CIA-43milkymist: Sebastien Bourdeauducq master * rba6271d / (8 files in 4 dirs): Support video mode switching - http://bit.ly/gzq2DZ15:47
Action: lekernel is using the flickernoise GUI in 1024x768 atm :)16:04
CIA-43flickernoise: Sebastien Bourdeauducq master * re7498df / src/fb.c : Detect screen resolution at start up - http://bit.ly/gP3CgA16:06
CIA-43mtk: Sebastien Bourdeauducq master * rf3ff0f5 / lib/scrdrv.c : Remove hardcoded resolution - http://bit.ly/hoX4hv16:06
CIA-43rtems-milkymist: Sebastien Bourdeauducq master * r6ac350f / c/src/lib/libbsp/lm32/milkymist/include/system_conf.h : Add all definitions for VGA registers - http://bit.ly/eQbLaJ16:16
CIA-43flickernoise: Sebastien Bourdeauducq master * r81bdecd / src/shellext.c : fbgrab: detect screen resolution - http://bit.ly/dSQUzg16:43
mwallelekernel: btw we wont have to modify the bios serial upload protocol20:55
mwalleim using a BREAK character20:56
mwallethus i've only needed to add support for that in the uart transceiver20:56
lekernelhm, what's that? keeping the line at 0 for more than one byte and no stop bit?20:58
lekernelcan it be done with common serial port hardware and drivers at the other (PC) end?20:59
mwallelekernel: yeah violating the stop bit21:03
mwallethere is a short break (length between one and two frames) and a long break character (longer thatn two frames)21:03
mwalleall modern serial transceivers should be able to generate one :)21:04
lekernelworst case I guess we can 'emulate' it on the PC side by setting a baudrate too low and transmitting a zero character21:04
mwalleyeah, lol :)21:04
lekernellol: http://www.elmelectronics.com/ebench.html#ELM46021:14
lekernelI found that crap when looking for info about how to send rs232 breaks21:14
lekernelELM electronics has a "break detector" circuit21:14
lekernelI guess they're programmed attinys/pic or something like that21:14
mwallelekernel: lol22:26
mwallelekernel: the gdb stub will need 6kb/2kb rom/ram22:27
lekernel8kb in total?22:27
lekernelshould be ok i think...22:28
lekernelwe have that much spare BRAM afaik22:28
mwalleunfortunately it is hard to mux gdb packets and console.. atm i did a tx redirection with the help of the uart core22:30
mwallethere are some scripts that intercepts the serial port traffic and looking for gdb packets and split them from normal data, but that wont work out of the box22:31
mwallegdb supports 'systemcalls' eg read and write to stdin/stdout/stderr, but that requires an application that is 'gdb aware'22:32
mwallegn8 :)22:35
mwalle12.142ns sys_clk period with one breakpoint22:36
mwallethe new ise seems to be a lot better :)=22:39
CIA-43mtk: Sebastien Bourdeauducq master * r0789f9d / lib/gfx_functions.h : Fixed text antialiasing - http://bit.ly/hBuztv23:04
CIA-43mtk: Sebastien Bourdeauducq master * r7a7bc76 / (7 files): Dark blue color theme - http://bit.ly/ijYerq23:46
--- Tue Mar 29 201100:00

Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!