<lekernel> plasma's just a toy project
<aw> xiangfu, after using  http://milkymist.org/msd/msd-dec2010.tar.bz2 , what's the desktop's color you have with OS RTEMS 4.10.99.0?
<xiangfu> aw: light-blue
<aw> after I reflashing the new msd, my color from dark blue to light blue.
<aw> xiangfu, so your color is kept with the same old one?
<xiangfu> aw: I can not remember the default RTEMS version. after reflash the desktop goto light-blue.
<xiangfu> aw: here is two videos before and after flash: http://www.openmobilefree.net/other/downloads/Milkymist/
<aw> xiangfu, i can pretty sure your old desk top color must be dark blue! now mine is http://en.qi-hardware.com/w/images/6/68/M1rc2_0x2c_splash_wrongbackgroundcolor.jpg
<xiangfu> aw: I don't know where to configure the desktop.
<aw> xiangfu, me either.
<aw> xiangfu, with xilinx tool, i think i can. but with 'jtag' tool i don't know.
<xiangfu> aw: oh.
<aw> is there anyone that tried to click "reboot" button successfully on Flicknoise 0.2 about 6 ~ 7 times then later serial/vga screen msg jumped into >BIOS shown as "No boot medium found"?
<aw> then type cmd 'reboot' in serial console then M1 shows up normal control panel again? What possible reasons will cause it?
<wolfspraul> aw: I think lekernel already mentioned those might be software bugs somewhere later in the bootup process. nothing to worry about for you, I think.
<wolfspraul> of course I agree it would be better to fix it earlier, even if in software, so we know this is not something that is caused by a hardware weakness still.
<aw> wolfspraul, okay..so it there somewhere that shows all happened bugs? i don't know yet..
<wolfspraul> but if it doesn't fix into the software priorities at this time, maybe we can safely assume it's not something we need to worry about on the hardware side?
<wolfspraul> I don't think so. Maybe this is a good task for xiangfu ?
<wolfspraul> xiangfu - can you try to reproduce Adam's problem? After you can reproduce it, can you try to track it down/fix it?
<wolfspraul> :-)
<wolfspraul> maybe a bit too early/difficult right now, but if it's reproducible at least it's fun to go after an actual bug...
<aw> yeah..because you know that we are not familiar with fpga s/w itself. if some somewhere records them then I can also search current status. well
<aw> seems i have to record myself first.
<wolfspraul> it's good that you are reporting strange things you see. we are aiming for a really stable and polished product.
<xiangfu> wolfspraul: ok. I can try to reproduce the bug. but first I would like work on compile toolchain and rtems first :)
<aw> the symptom on my site is easiler to reproduce it which i am not sure that maybe the M1 board h/w has been already haven something wrong in my  frequent "fast-power-cycling" before. so after I reflash with the new steps of 'jtag' tool, it can be easily shown on my board.
<aw> so  later if xiangfu can not easily reproduce my same symptom. then I can know it's my board problem probably. :-)
<wolfspraul> aw: no. that sounds excessive.
<wolfspraul> let's see... The problem you have means that the m1 will not fully boot up, right?
<wolfspraul> but the problem does not persist, i.e. you just need to power cycle again, and then it boots?
<wolfspraul> you don't even need to reflash to make it boot again, just power cycle?
<wolfspraul> let's assume that's the case. then - you are not tracking down a known or suspected hardware bug right now, or are you?
<aw> wolfspraul, no, the symptom i described above is i tried to click 'Reboot' on s/w control panel. then later it jumped into >BIOS
<wolfspraul> yes
<wolfspraul> but then you just power cycle and it boots again, correct?
<aw> then I typed 'reboot' under >BIOS then it can boot and shows up control panel...yes if later I power cycle and it boots again.
<wolfspraul> ok
<wolfspraul> that means the impact of the bug to the end user is very small, we have a very easy 'workaround' (simple power cycle)
<wolfspraul> in addition, you are not currently tracing down any suspected hardware bug, or are you?
<wolfspraul> so it's just a behavior (bug) you noticed, and reported (which is good).
<wolfspraul> do you have a suspicion or idea how this could relate to something we can fix on the hardware/electronic/layout side?
<wolfspraul> if not - just hand the bug over to xiangfu to reproduce and maybe fix, and forget about it :-)
<wolfspraul> if xiangfu cannot reproduce it - no problem, not worth further investigations on your side, UNLESS you have a suspicion or idea how to fix it in hardware by yourself
<wolfspraul> otherwise we get stuck with multiple people on problems of very little or no value
<aw> hmm..i am not working on suspected h/w ...i just curious that trying to see if any reset signals from fpga when I tried to click more time on "Reboot" button...
<wolfspraul> yes, exactly. so you have no suspicion you are tracing/following right now.
<wolfspraul> that means - you hand the bug to xiangfu. but - whether xiangfu can or cannot reproduce it is not so important now, if he cannot reproduce it we just leave it sitting there.
<aw> since I am going to do the patch on reversed polarity work, so meanwhile I played it for a while. :-)
<wolfspraul> otherwise I feel we are hunting ghosts, and spending our valuable resources on that while we have far more valuable things that are totally open
<aw> wolfspraul, yeah..okay
<wolfspraul> definitely, it's good that you report anything strange you see.
<wolfspraul> even if you just see it once, and then it goes away.
<wolfspraul> but if xiangfu cannot reproduce, that doesn't mean it goes back to you for further investigation.
<wolfspraul> if he cannot reproduce, that means we leave it sitting just like that.
<wolfspraul> UNLESS you have independent idea of your own what you think a hardware cause might be. If you don't have such an idea, leave the unreproducible bug sitting there.
<aw_> yeah~leave it sitting there now. :-)
<wolfspraul> yes. this is just my thinking, let's see what lekernel says...
<Fallenou> hi xiangfu
<Fallenou> what is your Makefile for ? to compile the lm32 toolchain ?
<xiangfu> Fallenou: yes.
<Fallenou> ok nice :)
<Fallenou> is it working ?
<kristianpaul> nice mm1 case feedback from wolfgang :-)
<Fallenou> sure
<kristianpaul> xiangfu: hi !!
<xiangfu> kristianpaul: hi
<kristianpaul> wow i was thiking about you right now ;)
<kristianpaul> is adam using last firmware?
<kristianpaul> i read the backlog, but i just could not ask him..
<lekernel> hi xiangfu
<xiangfu> lekernel: Hi
<lekernel> well, the different background is something to be expected and is totally normal :)
<lekernel> don't worry about such details...
<kristianpaul> :-)
<lekernel> the app tries to load /flash/wallpaper.png and /memcard/wallpaper.png (in this order)
<xiangfu> lekernel: ok. one thing. can you please setup a account on milkymist wiki :http://www.milkymist.org/wiki/index.php?title=Main_Page
<xiangfu> lekernel: I would like username "xiangfu" :)
<lekernel> and 0.2 uses the yaffs2 filesystem and cannot read the old flash files... therefore cannot load the previous background
<lekernel> xiangfu: you can create an account now
<lekernel> just tell me when it's done so I can disable it again
<lekernel> same for others on this chan... if you need accounts
<xiangfu> lekernel: done . thanks. "Your account has been created. Do not forget to change your Milkymist Wiki preferences. " :)
<xiangfu> kristianpaul: thanks for the URL about compile lm32-rtems toolchain shell file: http://home.gwu.edu/~cssmith/LuaRtems/RTEMS_Tools.html
<kristianpaul> i wonder if it works..
<kristianpaul> i dint try it yet
<xiangfu> kristianpaul: me ether. but my Makefile work fine in my notebook :) now I got those commands: http://pastebin.com/uBBqshQG
<kristianpaul> great !
<kristianpaul> time to compile rtems bsp fot the milkymist one :-)
<xiangfu> how about add a default RTEMS_MAKEFILE_PATH value: +RTEMS_MAKEFILE_PATH?=/opt/rtems-4.11/lm32-rtems4.11/milkymist/
<xiangfu> kristianpaul: next step maybe try to write a makefile  include those http://www.milkymist.org/wiki/index.php?title=Flickernoise_build_instructions
<kristianpaul> :D
<kristianpaul> I think Fallenou and i will be really happy with the flicernoise makefile :-)
<kristianpaul> flickernoise**
<kristianpaul> xiangfu: (rtme_makefile_path) for now i guess is okay, but rtems version should be a variable easy to change
<kristianpaul> but there is long time until that i think
<Fallenou> oh sure
<Fallenou> building the toolchain is not a problem for me
<Fallenou> but the Makefile is a good idea
<Fallenou> but building flickernoise is really a pain in the ass
<Fallenou> too much dependencies
<Fallenou> a Makefile is REALLY appreciated :)
<xiangfu> kristianpaul: how about this one: http://pastebin.com/Wh6YR9Qe
<Fallenou> a makefile fetching all the flickernoise dependencies and then building them
<Fallenou> and installing them
<Fallenou> would be awesome
<Fallenou> makefile or shell script, whatever
<xiangfu> Fallenou: I like makefile :)
<Fallenou> I'm fine with it :)
<Fallenou> as long as I can type one command, go drink a coffee
<Fallenou> and when I come back everything is built
<xiangfu> Fallenou: yes. that is the plan.
<Fallenou> then it's wonderful :) I am looking forward to it
<CIA-37> milkymist: Sebastien Bourdeauducq master * r01b2c9e / (4 files in 2 dirs): Add GPL headers - http://bit.ly/fTvIsG
<Fallenou> lekernel: thanks !
<kristianpaul> xiangfu: yeah, looks good
<CIA-37> flickernoise: Sebastien Bourdeauducq master * r95557d9 / src/Makefile : add default RTEMS_MAKEFILE_PATH (Xiangfu) - http://bit.ly/feqCqY
<CIA-37> flickernoise: Sebastien Bourdeauducq master * r6bb8c45 / (4 files): clean up flash.sh a little, remove some duplicate code (Xiangfu) - http://bit.ly/dNfgBy
<Fallenou> i've put the RTEMS_MAKEFILE_PATH in my .bashrc
<Fallenou> so it's not really a problem
<Fallenou> compiling flickernoise dependencies is
<kristianpaul> ;-)
<Fallenou> (sorry to insist :p)
<kristianpaul> The dma in mm1 is based on a bus mastering (i donk think so) or there is an dma controller (fmlarb) ?
<kristianpaul> Sorry if i'm not clear i still a bit confused undersand dma implementation
<Fallenou> actually I don't know how the dma works
<Fallenou> that's a good question
<Fallenou> let me go back home
<Fallenou> I will try to figure that out
<Fallenou> *going back home*
<kristianpaul> Fallenou: how works in sofware for you?
<kristianpaul> is it already maped i guess
<kristianpaul> sdsdsdsdsdsdsddsaaaa
<kristianpaul> damit
<kristianpaul> hmm xbar
<kristianpaul> the other bus was the fml
<kristianpaul> definittelly it is, i wonder now why stop checking it on sunday.. :/
<Fallenou> kristianpaul: to do memory -> ethernet, I just give the start address, and the size to the ethernet core
<Fallenou> So maybe it's the ethernet code itself which is doing the dma
<Fallenou> same thing for ethernet -> memory transfers
<kristianpaul> s/dma/swich  :-) ?
<kristianpaul> switch
<Fallenou> is back
<Fallenou> no no dma
<kristianpaul> xbar.v is from sep 2010 so before..
<kristianpaul> hmm :/
<mwalle> mh?
<mwalle> ethernet is a bus master
<mwalle> so it does dma
<mwalle> itself
<kristianpaul> ah
<mwalle> have a look at system.v (iirC)
<mwalle> there are all bus master listed
<kristianpaul> yes, i'm just trying do understand the dma internals a bit
<kristianpaul> need add another core to hist local branch with dma support
<Fallenou> is it Joachim Steiger who did the two case designs for Milkymist One ?
<larsc> yes, his nick is roh
<Fallenou> ok thanks :)
<Fallenou> kristianpaul: your blog is down, isn't it ?