<lekernel> kristianpaul: take screenshots (ctrl-f12) at labsurlab :)
<lekernel> btw it will freeze for a dozen seconds atm... don't reboot
<terpstra_> lekernel, !!! -- do i understand correctly that mwalle's gdbstub is using some milkymist specific uart and not the LM32's debug uart?
<lekernel> yes
<terpstra_> rofl
<terpstra_> no wonder i can't make it work :)
<lekernel> there's only the lm32 core we use here... everything else is custom
<terpstra_> yes, but the lm32 has a jtag cable and debug unit
<terpstra_> anyway
<terpstra_> i get it now
<lekernel> just use our uart core :) any problem with it?
<terpstra_> i have a jtag cable already connected to my chip?
<terpstra_> easier to just tweak his gpio stuff to use JTX and JRX
<lekernel> ah, you were talking about the JTAG UART
<terpstra_> then i should be able to run his debug rom
<terpstra_> yeah, his code uses your uart instead of the lm32 uart
<terpstra_> i have a nice reliable link to the lm32 jtag uart and want to run gdb on it
<lekernel> the problem with JTAG UARTs is they need specific hardware and software to get to work... which is why I didn't go this way
<terpstra_> fair enough
<lekernel> the current UART can be used easily with any serial cable and any driver
<terpstra_> well, i have that 'special' software now
<terpstra_> and i don't feel like wiring a uart to my board :)
<terpstra_> you have some sort of magical control unit at memory address 0x1000 ?
<terpstra_> ahh - isee
<terpstra_> CSR_SYSTEM_ID = 1 differs from "b r0" how ?
<terpstra_> very cool. i have it working now. :)
<terpstra_> lunch time.
<Fallenou> flickernoise wallpaper looks like an Apple wallpaper :')
<Fallenou> troll troll
<lekernel> perfect!
<lekernel> a lot of people love Apple products
<lekernel> more than they love free software in fact
<lekernel> :)
<lekernel> it's also a GNOME wallpaper btw
<terpstra_> lekernel, in ml401-flasher.c, is there a reason you don't always use bulk_cycle instead of cycle?
<lekernel> hum, I don't remember
<lekernel> you mean, why use the bulk EP and not bit bang directly with control transfers?
<lekernel> because it's slow
<terpstra_> i mean why not ALWAYS use bulk
<terpstra_> bulk is faster i assume
<lekernel> ha
<lekernel> yeah, it's faster
<lekernel> but I don't remember the reason (if any) to use control
<xiangfu> lekernel: Hi
<lekernel> hi
<xiangfu> sorry for my bad English. did I mis-understand you? you mean only include the "comet.png" in data partition image. not (three wallpapers and set comet.png as default)?
<lekernel> yeah, scratch the other wallpapers
<xiangfu> ok. then one small question :). why not three wallpapers? is there something wrong with those image license?
<lekernel> one has minor licensing problems and the other isn't as good imo (and all increase the flashing time)
<xiangfu> lekernel: got it. I will remove them.
<lekernel> do the subfolders work btw?
<lekernel> I mean you can access the files in the subfolders from RTEMS?
<lekernel> it seems there are some bugs there... until this is fixed let's put all the files at the root of the flash
<xiangfu> I can access all file under subfolders. without any problem.
<lekernel> try deleting files in those subfolders, or adding files...
<xiangfu> for now. I only meet ethernet bug.(ftp)
<xiangfu> trying now....
<lekernel> upgrade rtems.. I fixed a couple of them yesterday
<xiangfu> oh. great. I will test in serial console first.
<kristianpaul> new msd!!, i'll flash it later before dorkbot :-)
<xiangfu> lekernel: http://pastebin.com/tAqXJAqW
<lekernel> well, yeah
<xiangfu> you can see "/flash/wallpapers/a/b/c/"
<lekernel> [/flash/wallpapers] # mkdir a
<lekernel> [/flash/wallpapers] # mkdir a/b
<lekernel> mkdir 'a/b' failed:No such file or directory
<lekernel> this is the bug I'm talking about
<lekernel> fortunately it's a 100% reproducible one :)
<xiangfu> oh. I thought it's lack of rtems :)
<xiangfu> kristianpaul: I still not send out the mail. will do that tomorrow.
<lekernel> [/flash/wallpapers/a/b/c] # cp /flash/wallpapers/Comet.png ./a.png
<lekernel> ./a.png: No such file or directory
<lekernel> same problem here
<lekernel> and with FTP it's similar
<xiangfu> lekernel: ok. I will look into this bug.
<xiangfu> lekernel:  and I will try to send the mm-mkyaffs2image patch to yaffs2 upstream. do you have any advice. before I send out the patch?  :)
<lekernel> you can also try to upstream the other Milkymist support patches
<xiangfu> kristianpaul: you can also try data partition image. then give some feedback :) http://www.milkymist.org/wiki/index.php?title=Flashing_the_Milkymist_One#flash_data_partition
<lekernel> I tried to do so, was ignored/dismissed, I gave up, then silence for ~2 months, then they came back with a very polite message thanking me for my submission and saying they would merge it
<lekernel> afaik they did not yet
<lekernel> RTEMS patches should be upstreamed too (imo more important than YAFFS, and easier too)
<xiangfu> lekernel: then I can remind them in next few days.
<xiangfu> lekernel: yes RTEMS is more important. write  down them to my TODO list.
<lekernel> imo you should just have to diff src/c/lib/libbsp/lm32
<lekernel> afaik no one else touched it in the RTEMS tree, so my version should always be the most up to date
<lekernel> and I almost didn't touch the rest (platform independent) of the RTEMS code
<xiangfu> is this "Yann Sionneau <yann.sionneau@telecom-sudparis.eu>" also work on Milkymist one. or it's a upstream committer? rtems lm32 maintainer?
<lekernel> he's Fallenou
<xiangfu> oh
<lekernel> the RTEMS LM32 maintainer does nothing... I asked him to upgrade the EVR code to the new RTEMS IRQ API (a simple thing to do btw) when I upgraded this for all LM32 platforms, and that was already too much
<lekernel> answered the LM32 port was "a toy" "nothing serious" or something like that
<lekernel> so, my patches break EVR, but I don't think that's something we should worry about :-)
<xiangfu> oh. we are serious :)
<lekernel> sure. and because of that the LM32 port gets modern IRQ code. if the EVR doesn't, that's not a serious problem.
<roh> whats evr?
<lekernel> the original LM32 system and board from lattice
<roh> ah. who gives a shit
<xiangfu_> lekernel:  same question. what is EVR. (searching...)
<lekernel> the original LM32 system and board from lattice
<xiangfu_> thanks.
<xiangfu_> time for sleep. see you
<lekernel> good nigh
<lekernel> t
<rofl0r> greetings
<rofl0r> lekernel, which mtk files specify how stuff is drawn on the screen ? i wanna try to get it to work on directfb
<mw1> lekernel: is there anything else beside the user/pass i have to set to enable the ftp server?
<Fallenou> mw1: nop
<mw1> mh doesnt work for me
<mw1> ping works
<Fallenou> oh strange
<Fallenou> usually just setting uer and pwd is enough
<Fallenou> user*
<mwalle> is the ftp server always enabled?
<mwalle> because i get connection timed out
<Fallenou> don't know more sorry, last time I tested on qemu, I just had to enter the user /pw :x
<mwalle> write(5, "$X400007e0,7e0:5\345\0\200\24\204\0\1<\245\0\2\264}\3\30\0"..., 2048) = 2048
<lekernel> mwalle: just set user and pwd and theoretically it works
<lekernel> port 21
<mwalle> --- 192.168.4.77 ping statistics ---
<mwalle> 1 packets transmitted, 1 received, 0% packet loss, time 0ms
<mwalle> rtt min/avg/max/mdev = 0.682/0.682/0.682/0.000 ms
<mwalle> [mw@thanatos ~]$ telnet 192.168.4.77 21
<mwalle> Trying 192.168.4.77...
<mwalle> telnet: Unable to connect to remote host: Connection timed out
<lekernel> wtf
<lekernel> works for me
<lekernel> is the telnet server broken as well?
<mwalle> yep
<lekernel> uhm, weird...
<lekernel> what binary are you using? msd?
<mwalle> the one you announced today
<lekernel_> i'm connected to the board just now... both telnet + ftp
<lekernel_> with the very same binary
<lekernel_> maybe you have a firewall enabled or something?
<mwalle> iptables -L shows nothing :) theres a fritzbox in between
<mwalle> i'll try it directly tomorrow
<mwalle> lekernel_: a directly connected linux laptop wont work too
<mwalle> gn8
<lekernel_> gn8
<larsc> hmpf, this is new. network-manager is blocking my /dev/ttyUSB0
<roh> larsc: hrhr.. probing for a modem (gsm)
<roh> should make it free after splitseconds usually
<roh> if not, disconnect the serial device and only plug the usb-serial, then after some seconds the device
<larsc> `apt-get purge modem-manager` solved it...
<roh> hrhr
<lekernel_> roh: do you think one could make a decent CVBS signal generator out of a 8-bit DAC?
<lekernel_> hm, with oversampling maybe... the one on MM1 goes up to 140MHz
<lekernel_> so I see two options: 1) one channel, oversampling, passive low pass filter
<lekernel_> 2) two or three channels, active analogue circuit to compute 2^16*channel1 + 2^8*channel2 + channel3
<larsc> lekernel_: do i need a newer vgacore for the clksel register?
<lekernel_> yes
<larsc> ok
<lekernel_> you can use the bitstream I just posted
<lekernel> imo oversampling is great... never do in hardware what can be done in software :)
<lekernel> and the oversampling circuit should only be a few dozen LUTs
<lekernel> larsc: good
<larsc> so that one should have support for clksel?
<lekernel> yes
<larsc> ok
<larsc> maybe i did something wrong
<roh> lekernel: decent? nope
<roh> need the sync also
<lekernel> roh: so what would you recommend to get tv-out on milkymist?
<roh> use vga and different timings
<lekernel> oversampling at 140MHz should definitely do the trick imo... CVBS is only 8MHz bandwidth
<roh> generate composite sync on one pin and use an adapter to scart
<lekernel> sync isn't that low compared to active video, is it?
<roh> cvbs itself.. dunno.. i dont really have usecases for that anymore. its like the lowest common denominator in the worst case of video.. besides that... i rather chose any other possibility
<roh> lekernel: not sure.
<lekernel> i'd like to keep the analogue part as simple (cheap) as possible :)
<larsc> lekernel: ok, works fine now. i just wrote the bitstream to the wrong location...
<lekernel> so sync would use about 26% of the dynamic range of the DAC
<lekernel> mh, otoh oversampling wouldn't do wonders. at 140MHz it would only add 1-2 bits of extra precision
<lekernel> so that's a 9-10 bit DAC
<roh> lekernel: sure your vga dac cant do cvbs as alternative?
<lekernel> it can
<lekernel> it's a dumb DAC
<lekernel> 3x8-bit in, 3x analogue color channels out
<lekernel> but I'm worried about 8-bit not being enough to get a decent picture quality
<lekernel> when used for CVBS
<roh> i see. so it cant do 'cvbs generation from rgb'
<lekernel> so as I said: to gain more resolution, either oversample, or combine the three channels with an analogue circuit
<lekernel> no, but the fpga can
<roh> lekernel: with expensive additional hw
<lekernel> huh?
<roh> i dont really see the need for that anymore (cvbs)
<roh> i think it should be possible to do it with a 'cable mod'
<roh> vga to scart and 'weird' timing
<lekernel> I don't expect the CVBS generator to take more than 1-2% of the FPGA resources
<lekernel> well you need colorspace conversion too
<roh> some resistors or so in the cable to combine H and V sync to feed to the cvbs pin as 'csync'
<lekernel> and color subcarrier generation
<roh> all tv sets fo the last 10 years eat rgb directly and it gives a much better picture than possible on cvbs due to the reduced bandwith there
<lekernel> both can be done as with FPGA DSP
<roh> lekernel: you only need sync on the cvbs pin. r g and b are just wires.. maybe with some voltage divider to 0.7vpp
<lekernel> yup, but I want CVBS, not SCART
<roh> whatfor?
<lekernel> driving cheap video mixers, cables and projectors
<roh> low end people?
<lekernel> not only, some large expensive displays take CVBS too
<roh> then it was not expensive or the buyer maximum stupid. sorry.
<roh> should be <40E in asia
<lekernel> this can be put into the fpga :p
<lekernel> less latency, possibly better picture
<lekernel> what is this VGA to RCA cable you pointed to btw?
<lekernel> when I asked about 720p