<CIA-43> milkymist: Michael Walle master * rafcb5f6 / cores/uart/rtl/uart_transceiver.v : uart: begin sampling with falling edge - http://bit.ly/ec3I4Z
<CIA-43> milkymist: Michael Walle master * r9ff8deb / cores/uart/rtl/uart.v : uart: fix thru bit initialization - http://bit.ly/gExhuO
<CIA-43> milkymist: Michael Walle master * rbaf9c09 / (cores/uart/rtl/uart.v cores/uart/rtl/uart_transceiver.v):
<CIA-43> milkymist: uart: add break support
<CIA-43> milkymist: This patch adds UART BREAK support. A BREAK signal violates the framing by
<CIA-43> milkymist: transmitting a logical 0 for a period that is at least longer than one
<CIA-43> milkymist: frame. - http://bit.ly/g622RM
<wolfspraul> blist
<wolfspraul> oops :-)
<wolfspraul> xiangfu: after reflashing your binaries, I could not find any patches installed?
<wolfspraul> are they somewhere or just no patches?
<xiangfu> wolfspraul: no patches.
<wolfspraul> I reflashed rejon's m1 with your binaries, but now it's actually less usable than before :-) What is the easiest way for rejon to get a bunch of patches onto his m1 now?
<xiangfu> I copy those patches to sd card.
<wolfspraul> when you create binaries, can you include the full latest set of patches?
<xiangfu> copy patches to sd card.
<wolfspraul> where are the patches? (url)
<xiangfu> wolfspraul: hmm... not easy. there only 4MB for OS. (flickernoise)
<wolfspraul> ok but there is another 24 mb or so data partition, no?
<xiangfu> wolfspraul: yes. working on that now.
<xiangfu> wolfspraul: two method for now. 1 make  mkyaffs2image works with milkymist one.
<xiangfu> 2. dump the data partition from one device
<xiangfu> I have tried those 2 method. both not working. :(
<lekernel> wolfspraul: worst case you can erase the flash partition and upload the patches with FTP
<xiangfu> wolfspraul: copy a png file named "wallpaper.png" . when mm1 boot it's automatic log (just fyi)
<wolfspraul> we need dumbed down step-by-step instructions for Jon ;-)
<wolfspraul> xiangfu: log?
<wolfspraul> don't understand
<wolfspraul> it sounds like the easiest is if Jon takes a small FAT formatted memory card, and copies the patches from that URL to the root folder
<wolfspraul> that should work?
<xiangfu> yes. correct.
<xiangfu> also copy a wallpaper.png to this memory card.
<wolfspraul> ah ok
<rejon> wolfspraul die!
<wolfspraul> I see the 4 folders of .fnp patches at that url, so looks good
<rejon> i am pretty dumb though
<wolfspraul> rejon: sorry I just didn't prepare to that point, so we only found out there are no patches this morning :-)
<wolfspraul> which is great, nothing better than get a bunch of shitty reality right in my face :-)
<wolfspraul> rejon: try the memory card path
<rejon> ha
<wolfspraul> hopefully it will work
<rejon> ok
<rejon> is it on the wiki
<wolfspraul> some people have reported problems with memory cards
<rejon> i can't keep up with you smart people right now
<wolfspraul> just copy files!
<wolfspraul> 1. fat formatted memory card
<wolfspraul> 3. reboot m1
<wolfspraul> then either it shows up or not :-)
<lekernel> hm, for copying files you'll need the shell for now
<wolfspraul> he can just leave the card in the m1, no?
<wolfspraul> always run the patches from there, why not?
<lekernel> yeah, too
<wolfspraul> lekernel: different question. how do you feel about changing the power supply circuit of m1 to something like some Arduinos have, with a regulator that supports 6-20V or so, fairly robust... ?
<wolfspraul> not for rc3, but I'm wondering how you feel about it in general, say for rc4 or so
<lekernel> waste of time
<wolfspraul> you wouldn't need to spend any time on it. so that means you have no problem with it?
<rejon> better than frying your mm1
<rejon> just showed us embassy guy milkymist
<lekernel> no... except that you'd have two different PSU
<lekernel> so far we have exactly 0 fried M1s because of power supply problems, so....
<wolfspraul> yes there are some issues in switching, but they are all minor and if I believe this is not good (robust enough), then I rather switch earlier than later.
<xiangfu> uploaded two wallpapers we talked about before.
<wolfspraul> lekernel: it sounds like you are not opposed to it, only that you feel 'waste of time'
<wolfspraul> which I can actually understand from your perspective, don't get me wrong
<wolfspraul> apart from this chat you will never hear about it anymore :-)
<wolfspraul> but there are stupid people like rejon and me in the world, we just plug in stuff and turn things on :-)
<wolfspraul> unfortunately these stupid people have a lot of money and may very well buy m1, one day...
<wolfspraul> this is definitely not for rc3, I want to get rc3 done asap
<wolfspraul> no worries
<rejon> esp. if there is a camera power supply in that box
<wolfspraul> rejon: and what did the embassy guy think?
<lekernel> well, also keep in mind that switching regulators are prone to EMI problems. we should go to CE/FCC tests again if you change it.
<wolfspraul> do they want to buy one to run in the lobby somewhere?
<wolfspraul> or in their bar, if they have one :-)
<rejon> they love it, he kind of poked fun of the name slightly
<rejon> will try to support press stuff is their main help
<wolfspraul> he better not do that, we have Wikileaks documents about activities of embassy staff in Beijing
<rejon> meet n greet
<rejon> yeah, 1st time to meet him
<rejon> like 6-7 ppl came
<rejon> mostly firefox fans
<wolfspraul> you can always just tell them "BUY"
<rejon> bloggers, etc
<wolfspraul> I do support my customers
<wolfspraul> it's ready for end users now
<wolfspraul> I personally go there for updates, fixes, etc.
<rejon> yeah, i did
<wolfspraul> it's not a developer box
<wolfspraul> ok good
<wolfspraul> sales@sharism.cc
<rejon> they want to support anything we do in china
<wolfspraul> sales@sharism.cc
<rejon> but its pretty much limited
<wolfspraul> email me, and we are on track
<rejon> ha
<rejon> yeah, i told them to buy mm1
<wolfspraul> lekernel: yes sure, it's quite a bit of work.
<rejon> and purify their internet too
<rejon> hahah
<rejon> he will hook me up with others
<rejon> speculative shit
<wolfspraul> but without wanting to discredit your 'waste of time', the current power supply circuit is in no way 'end user ready'
<wolfspraul> rejon is American, and I got americanized in over 10 years
<wolfspraul> you have to dumb it down to the point that you could never even believe
<rejon> thanks for dumbing down for me
<wolfspraul> you cannot put a fork into the pre-made cake box, because the danger is too high that the customer would try to eat the fork and hurt themselves!
<wolfspraul> that kind of thing...
<rejon> just get sued
<wolfspraul> oh sure
<lekernel> having zener+polyswitch fuse will already reduce the risk of damage by a fair bit
<rejon> fried mm1 is expensive for returns at this point
<wolfspraul> yes, we do that in rc3
<lekernel> rejon: did you fry your board?
<rejon> lekernel : i should try it
<rejon> freedom fries
<wolfspraul> don't worry, we will not bother you with this. I just wanted to see whether you had any strong reasons _AGAINST_ a more robust regulator.
<wolfspraul> I understand where you are coming from.
<lekernel> wolfspraul: you can try applying 20V to the protection circuit and see what happens
<wolfspraul> we had real WARS at Openmoko over this
<wolfspraul> some people believe in making more robust, other say that's butt stupid because it can never be totally robust
<lekernel> then decide whether it's worth it to work on that regulator that supports 20V
<wolfspraul> like lightning strike or so :-)
<wolfspraul> of course the two camps can fight forever because both have a lot of arguments
<wolfspraul> we don't need to repeat that
<wolfspraul> I do understand you, but I may still go for some more robustness at some point.
<lekernel> imo, with properly chosen zener/fuse, that circuit should protect the board at 20V
<wolfspraul> when you don't notice it, and when it doesn't cause any delays :-)
<lekernel> I'm not sure the regulator would give more robustness compared to zener+fuse
<wolfspraul> ok, even better
<wolfspraul> I will look into that.
<lekernel> just ask Adam to supply 20V to the chosen zener+fuse (alone, not on the board) and measure the output voltage...
<wolfspraul> ok, will check
<wolfspraul> rejon: you should get a projector like the one I have
<wolfspraul> how did you like it? in terms of effectiveness of demoing I mean...
<rejon> wolfspraul great
<wolfspraul> if I take a small power strip with me, all I need is one power plug, and not too bright room/environment, and I'm good to go
<rejon> yeah, i'll look into
<rejon> yep, great, all fits in that case
<wolfspraul> at night will never be a problem
<wolfspraul> of course it's not as bright as a real big projector
<wolfspraul> but if one of those is there, I can still use that
<wolfspraul> and if not, that little thing is definitely better than a monitor, especially one I would have to lug around with me :-)
<wolfspraul> I need to find some sort of micro power strip
<wolfspraul> will keep my eyes open
<wolfspraul> with projector, camera, m1 I already need 3 now
<lekernel> rejon: ?
<rejon> oh, sorry, dude from usgovt
<rejon> wrongwindow
<xiangfu> the "mkyaffs2image.c" in yaffs. code style is a little strange.
<wolfspraul> rejon: cool, this is what I need for my m1 kit http://www.amazon.com/Monster-MP-OTG400-BK-Outlets/dp/B000F9YN2M
<rejon> yeah, i need one of those
<rejon> lekernel what issue tracker is being used on milkymist?
<rejon> seems like code is a lot of places
<rejon> hard to find on the site
<lekernel> all code is on github, I don't know where you managed to find "lots of places"
<rejon> aha
<rejon> lekernel ook, cool github is good
<lekernel> except urjtag and qemu which are in mwalle's repos and/or upstream
<rejon> ok
<rejon> tracking
<wpwrak> wolfspraul: (power supply) if you can find a suitable up/down converter, you may even be able to use the existing supply (if it can deliver a bit more current than actually needed)
<wpwrak> lekernel: it's not only protection but also makes it easier to replace the power supply, e.g., if lost, forgotten, or broken
<lekernel> suitable power supplies are only a few dollars at digikey
<lekernel> (and we can sell replacements)
<wpwrak> lekernel: having them shipped around the world can be crazily expensive. plus, what do you do if you need one on short notice ? e.g., because you've arrived at the club but your power supply is at the hotel room / at home ?
<wpwrak> lekernel: also, some places have local certification rules. so the one from digi-key might get confiscated by customs. (though in argentina, i only had them try to do this if the power supply was accompanied by something else)
<CIA-43> flickernoise: Sebastien Bourdeauducq master * r403acd1 / (src/filedialog.c src/flash.c): File dialog box: add extension on save - http://bit.ly/f7rLxQ
<Fallenou> xiangfu: indeed I think you cannot start an executable file from RTEMS shell
<Fallenou> xiangfu: you can just run "commands"
<Fallenou> so you have to put your program as a command
<xiangfu> Fallenou: it's not support on rtems. or only milkymist ?
<Fallenou> on RTEMS AFAIK
<xiangfu> Fallenou: thanks
<Fallenou> RTEMS is like a library, that you link to your application
<Fallenou> it's not like a real OS that loads programs
<Fallenou> you cannot load programs in RTEMS, it's the same in the shell
<Fallenou> but you can start "threads"
<Fallenou> so if your program is already built-in
<Fallenou> you can start it, if it's a thread
<Fallenou> (or a command, in rtems shell)
<Fallenou> there is no per-process memory mapping, no MMU support in rtems (and no mmu in lm32), no process support in rtems
<xiangfu> Fallenou: oh. yes. it's libs. not real os.
<Fallenou> rtems is basically a big library that does scheduling  among threads and interrupt management
<xiangfu> Fallenou: thanks again.
<Fallenou> xiangfu: there has been a thread about dinamically loading executable in rtems (started by kristianpaul for his lua interpreter)
<Fallenou> but it's not easy I guess :)
<Fallenou> and it's only supported on a few platforms
<Fallenou> you would have to port cexp on lm32
<Fallenou> and play with gcc bugs
<lekernel> there doesn't seem to be GCC bugs affecting CExp if you stick to C (no C++)
<lekernel> the lm32 c++ compiler is totally broken anyway
<Fallenou> this thread
<Fallenou> ok
<xiangfu> wow. seems this task is very hard for me :)
<Fallenou> so yes
<lekernel> xiangfu: don't do it. it's not worth it
<Fallenou> the best is really doing a shell command :)
<xiangfu> yes. sure. understand.
<lekernel> if you want dynamic loading of code, use linux :)
<CIA-43> flickernoise: Sebastien Bourdeauducq master * r35d905e / (src/sysconfig.c src/sysconfig.h src/sysettings.c): System settings: add language, resolution and wallpaper - http://bit.ly/hQKDcS
<CIA-43> mtk: Sebastien Bourdeauducq master * re5e25e0 / (include/mtklib.h lib/background.c): New wallpaper API - http://bit.ly/g7eQWB
<CIA-43> flickernoise: Sebastien Bourdeauducq master * rf006dce / (src/main.c src/sysconfig.c src/sysconfig.h): Wallpaper selection - http://bit.ly/g0hBPm
<CIA-43> mtk: Sebastien Bourdeauducq master * r9a0ef32 / (lib/edit.c lib/entry.c): CtrlA selects all text - http://bit.ly/fLnK82
<carlobar> hi, im tryng to run the lm32 processor and uclinux on a FPGA spartan 3. i know that the milkymist project is using RTEMS, but some time ago used uclinux... anyone know of a site to find uclinux developed by milkymist?
<carlobar> thanks
<kristianpaul> (if you want dynamic loading of code, use linux :)) i agree
<kristianpaul> hi carlobar :-)
<carlobar> hi  kristianpaul
<carlobar> these linux need MMU, right?
<kristianpaul> linux does
<kristianpaul> uclix not
<kristianpaul> uclinux*
<carlobar> i need uclinux, have you implemented it with the lm32 processor?
<kristianpaul> i think lekernel pointed to it already
<kristianpaul> pointed you*
<kristianpaul> carlobar: what you need it for?
<kristianpaul> i will siguest not to try linux for a real-word app, unless you are willing to develop missing drivers
<kristianpaul> rtems is the best suported so far :-)
<carlobar> :), i just need to execute some testbenches and made some performance measurements... but it has to be uclinux, because i need to compare it with the leon3 processor runing on uclinux
<kristianpaul> i see
<kristianpaul> i dunno if lars_ may have an already init to share? :-)
<kristianpaul> but worth to ask,
<lars_> lm has a example rootfs
<kristianpaul> carlobar: ^
<carlobar> hi lars_,  can you send me the example rootfs?
<carlobar> the rootfs have to be coupled with a kernel and a bootloader? im a little confused..
<kristianpaul> broma :p
<carlobar> thank you, i had seen it before (not in detail), but i read that it had problems: http://mailman.uclinux.org/pipermail/uclinux-dev/2010-February/002010.html
<carlobar> so i was searchig a version that had corrected t
<carlobar> these errors
<lars_> well its the only prebuild image afaik
<lars_> and it will work
<carlobar> ok, im going to start to study it.. if i have problems i will be back seeking for help :).. thank you
<mwalle> lekernel: maybe you have a better idea, if the break for the gdb stub is received just after a uart tx character is enqueued, there is a problem with the irq and pending state of the (shared) uart
<mwalle> atm im doing, blocking on "uart tx in progress" bit
<mwalle> (2) reading uart tx IP bit
<mwalle> (3) ack uart tx IP bit
<mwalle> (4) gdb stub takes over uart
<mwalle> (5) after gdb packet processing, eg leaving the stub, posting an uart tx irq it bit was set in (2)
<lekernel> sounds good
<mwalle> unfortunately this needs some more registers within the uart core and more resources on gdbstub :)
<lekernel> is there a problem with doing that?
<lekernel> well, I guess it's only a dozen more LUTs or so
<lekernel> the rest of the design uses 18K :)
<mwalle> otht i could defer the break until the tx transaction is finished and do a break after that
<mwalle> 6k is really small *fg*
<lekernel> yeah or defer the break
<lekernel> both solutions seem good to me
<mwalle> mh ok, let me sleep on it ;)
<mwalle> xml..
<mwalle> gn8
<lekernel> gn8
<lekernel> lol, very useless utilization of xml indeed
<lekernel> for extra crapware points they should have used a java parser