#milkymist IRC log for Tuesday, 2011-11-22

kristianpaulwpwrak: that xse-sane allow to use in the same shell the lm32-gcc ?01:19
wpwrakthere should be no conflict01:21
wpwraki kinda wonder if build_bitstream.sh would tell me if it found an error. or if we would just proceed with the old file and let me find it somewhere in the megabytes of diagnostics01:22
wpwraks/we/it/01:23
kristianpaulnot use that script01:23
kristianpaulah well it oes01:23
kristianpauldoes, some build.log01:23
kristianpauli wonder when i stoped using it..01:24
wpwrakso if there's an error, will it fail ? or will it just continue ?01:24
kristianpaulnow i just type time make soc.fpg | tee soclog under boards/milkymist-one/flash/01:24
wpwrakand yes, it's only a question of time until i get rid of it :) i really dislike those scripts that hide vital information from you01:24
kristianpaulerrors stop verything01:25
kristianpauland warnings pass silent...01:25
kristianpaulget rid of it, yes yes !01:25
wpwrakgood. then i either made no detectable errors so far ... or the thing is really slow at detecting them :)01:25
kristianpaulucf errors may take a while to show up01:26
kristianpaulbtw be _aware_ that by default soc and soc-rescue bitstream are build01:26
kristianpaulso you spend TWICE time syntheising !!01:27
wpwraki'm  a bit worried about the vast amount of warnings. is it normal to for verilog to have so many warnings ? it basically means they're useless01:27
wpwrakHMMM01:27
kristianpaul:_D01:27
kristianpaulplease confirm01:27
kristianpauli just had tha sad experience when get into M1 "hdl developmemnt"01:28
wpwraki looked for -rescue but didn't see anything. lemme have a closer look then01:28
kristianpaulyeah, actually i thing that is just present in boards/milkymist-one/flash/Makefile01:28
kristianpauljust share your timings, i'm curios how long it taks on a fast machine like yours :-)01:29
kristianpaultaks/takes01:30
wpwrakrescue would be in boards/milkymist-one/synthesis/build-rescue/01:30
wpwrakand i have nothing there. so i think i'm good01:30
kristianpaulphew01:30
wpwraka system with default config took about 25 minutes. with all peripherals except USB disabled, about 10 minutes01:31
kristianpaulwow01:31
wpwrakoh nice. errors are not reported as such01:31
wpwrakso maybe the 10 minutes were an incomplete build01:31
kristianpauldint said build fail?01:31
wpwrakoh, right01:32
kristianpauli think buid_bitstream report errors, at least with a generic fail..01:32
wpwrakvery discrete :)01:32
kristianpaul;)01:32
wpwrakokay, so system with nothing but USB, proper build, 10 min 35 sec01:32
kristianpaul not bad...01:33
wpwrakand my PC's CPU isn't all that fast. it's a Q6600. that was "modern" some 4 years ago01:33
kristianpaulseems i need a dual core machine at least, system with no thong but namuru (one correlator arm) takes 30minutes here :-|01:34
kristianpaulok01:34
kristianpaulthong/thing01:34
wpwrakpentium I, 60 MHz ? :)01:34
kristianpaulnah, amd sempron 2.4ghz01:34
kristianpaulthe cheapest 2 years ago :)01:35
wpwrakmaybe namru is complex then01:35
kristianpaulperhaps01:35
kristianpaultoo many mixers and counters :-)01:36
kristianpaulucf erros are the last to show from i remenber, and very dicusting after wait almost 80% of time01:36
kristianpaulbtw i think. you also can run all this synthesis steps one by one01:37
wpwrakit's more like 95% ...01:37
kristianpaulwpwrak: ;-)01:37
kristianpaulwhy? well to avoid repeat all of then.. afaik i nevr tried, i just have some logs from lekenerl trying to do P&R in parallel01:38
kristianpaullike a farm build or such, very intresting01:38
wpwrakwell, i have to admit that the DRC was right ..01:39
wpwrak"make" should take care of skipping steps that aren't necessary01:40
kristianpaulYES01:40
kristianpauli just hack the makefile for quick01:41
wpwraki don't see anything parallelizable there, though. but maybe that's just how the makefiles are written01:41
wpwrakparallel P&R would be nice - i have 4 cores to play with, so that would help :)01:42
wpwraknow, ERROR after 2 minutes01:42
GitHub143[autotest-m1] xiangfu pushed 1 new commit to master: http://git.io/3m2pcw01:46
GitHub143[autotest-m1/master] support new uart core - Xiangfu Liu01:46
Action: xiangfu try to follow recently milkymist develop. Sebastien have commit some pictures support code, great. 01:53
kristianpauloh01:53
wolfsprauland I am lobbying people to take on the Linux on M1 port :-)01:54
wolfspraulwolfy the beggar01:54
wolfspraul:-)01:54
kristianpauljpeg.. hope load fast01:54
kristianpaulwallpaper was not a great experience01:55
wolfspraulkristianpaul: I see we are making progress on expectation management :-)01:55
wpwrakaha ! the build script doesn't honor dependencies01:55
wolfspraul(I'm serious)01:55
kristianpaulwolfspraul: hum?01:55
wolfspraulexpectation management is so difficult.01:55
wpwraki changed system.v, and it didn't process it, because it had (incorrect) output from a previous run01:55
kristianpauli wonder what i did about that topic :-)01:55
wolfspraulkristianpaul: well, you hear about jpeg, but you are cautious as to how well it will actually perform. yet you are still excited to see it coming :-)01:56
wolfspraulGOOD!01:56
kristianpaul;_)01:56
wolfspraulbeing disappointed is not a good experience, ever01:56
kristianpauli see coming a jpeg boost core :-D01:56
wolfspraulso the skill in expectation management is to get people excited about something, but then still slightly over-deliver on what they expected01:56
kristianpaulor gif support? :-)01:56
wolfspraulyeah yeah01:56
wolfspraul:-)01:56
kristianpaul:-)01:56
wpwrakmaybe we can get hardware-accelerated PPM ;-)01:57
kristianpauljpeg not joking, wasnt stekern metionted some experience about it in the past?01:58
kristianpaulscrts***01:59
xiangfuwpwrak, (the build script doesn't honor dependencies) which one? scripts.git?02:01
kristianpaulllvm, lemon..02:01
kristianpauli guess?02:01
wpwrakmilkymist.git/build_bitstream.sh02:02
wpwrakwell, and also build_bios.sh for that matter :)02:02
wpwrake.g., change softusb/main.c and run make (without making libhal) it'll never know. you have to make libhal manually, then it's happy02:03
wpwrakthings are getting more interesting: ERROR:Pack:1654 - The timing-driven placement phase encountered an error.02:03
xiangfuwpwrak, then it maybe something woring with the boards/milkymist-one/synthesis/Makefile.xst02:04
wpwrakfunny, it's drive strength conflict :)02:04
kristianpaulindeed boards/milkymist-one/flash/ is a better place02:04
wpwrakwell, not strength. let's say driver type.02:04
wpwrakkristianpaul: synthesis/Makefile.xst is what gets invoked from flash/Makefile :)02:06
kristianpaulyes...02:07
wpwrakxiangfu: yeah, probably. the whole build system could use some cleaning. perhaps starting in rtems :) e.g., linux kernel-style short messages. CC foo.c instead of blah-gaga-gcc -Weird -madness -freak -B ../../../down/deeper/still-more/../../../../oops/lets/do/this/again/../finally -I ...02:08
wpwrakkristianpaul: the corollary is that some of the bugs you may observe could simply be build dependencies that weren't correctly handled :)02:09
wpwrakparticularly helpful with tests of the sort "if i change X, does this make the problem go away" ? you change, gazillions of lines scroll by, so you have no idea what was actually done, then you get the final binary. you try it and the problem is still there. so you think changing X didn't help. but in reality, you're still using the code before the change. so you'll never know. and your mental image of reality has distanced itself a litt02:11
wpwrakle more from objective reality.02:11
kristianpaulbugs, yes that why i still using the clean_all.sh :-)02:12
wpwrakheh :)02:12
wpwrakthere's a "clean" target in synthesis/Makefile.xst that looks suitably radical02:13
wpwrakyes ! it built02:13
xiangfuwpwrak, so there are three place needs cleanup: the softusb-input, the build_bitstream.sh and the script.git(the output style)02:14
wpwraksemi-incremental build. 8:45 :)02:14
xiangfuwpwrak, it needs about 45 mins in my computer.02:14
Action: kristianpaul not alone02:14
xiangfuwpwrak, compile whole bitstream and flickernoise needs about ~1 hour.02:15
wpwrakbuild_bios.sh (or something it calls), build_bitstream.sh (or something it calls), and the makefiles for the output style. i think scripts.git don't have anything to do with it02:15
wpwrakoh, that's a very reduced soc.fpg i'm building. the only peripheral is USB02:15
wpwraklet's see if it boots02:16
wpwrakyeah02:16
wpwraknow, the fun part. let's see if the debug signal is being emitted :)02:16
xiangfuwpwrak, ok. I wills tart with build_bios.sh.02:21
xiangfuwpwrak, ( change softusb/main.c and run make (without making libhal) it'll never know.) <-- about this. just checkout. didn't find any problem with softusb.02:21
wpwrakthe following test should work: 1) run build_bios 2) edit softusb/main.c, e.g., change the banner message. 3) make 4) run build_bios again 5) flash the new bios. 6) now, it should still show the old banner02:23
wpwrakto make it work, make -C software/bios clean && ./build_bios.sh02:24
wpwrakabout 5), the one in software/bios/bios.bin02:24
xiangfuabout 3) run make under softusb/ right?02:26
wpwrakyes02:27
xiangfuwpwrak, I will try to fix this first. :)02:29
wpwrakhave you been able to reproduce it ?02:30
xiangfudoing that now.02:33
xiangfuyes. I can reproduce that. (and I use the m1nor to reflash bios)02:39
wpwrakperfect ;-)02:39
wpwraki don;t know if you even need the "make" in softusb. maybe it happens without it, too02:40
xiangfuwpwrak, there are even more depends problem in softusb-input. :)02:49
wpwraki'm not surprised :)02:51
wolfspraulMilkymist One at amazon.com http://www.amazon.com/Milkymist-copyleft-hardware-synthesizer-complete/dp/B0064UUUC8/02:55
wolfspraulthanks to our ever supportive Danny Clark from freedomincluded.com02:56
kristianpaulwut? huh!!02:56
kristianpaulwow02:56
kristianpaulcheers for djclark !02:56
kristianpauli'm amazed about paper work involved to get this sellable in amazon02:59
kristianpauloh even lemote yeeloong in amazon, interesting03:00
kristianpaulnanonote !!!03:02
kristianpaul"We are not able to ship this item to your default shipping address. "arghh03:03
kristianpauloops this is not qi-hw03:03
wpwrakvictory ! i can see rx_pending on J21 :)03:03
wpwrakhttp://downloads.qi-hardware.com/people/werner/tmp/usb-D15rx_pending.png03:05
kristianpaulwhy the blur?03:05
wpwrakjust increased the contrast a bit03:05
wpwrakbecause of the infinite persistence :)03:06
wpwrakthe time rx_pending rises is a bit misleading03:10
wpwrakhere's a clearer image: http://downloads.qi-hardware.com/people/werner/tmp/usb-D15rx_pending-100ns.png03:11
wpwrakworst-case time to clear rx_pending is about 500 ns03:12
wpwrakbetween 510-520 ns03:15
xiangfuwpwrak, this patch fixed the depends03:25
xiangfuwpwrak, now we seems don't even needs this 'build_bios.sh' , I have add all libs depends to software/bios/Makefile03:26
xiangfuand connect the depends between softusb-input  and libhal. :)03:27
wpwraksounds as if you're on the right track :)03:28
wpwrakall those build scripts are a bit scary :) just "make" ought to do the job03:29
xiangfuwpwrak, yes. maybe I try to finish a 'makefile' under MMDIR :)03:30
xiangfuwpwrak, that what I am thinking. :)03:30
wpwrakthat would be cool03:30
xiangfuwpwrak, make flash-bios :)03:30
wpwrakyes. "make bios" and "make flash-bios"03:31
xiangfuwpwrak, I don't have commit right to milkymist.git. will try to send this patch to mailing list. then try to finish that makefile.03:31
xiangfuflash-bios: bios   :D03:31
wpwrak(dependency) yup :)03:32
qi-botThe Firmware build was successfull, see images here: http://fidelio.qi-hardware.com/~xiangfu/build-milkymist/milkymist-firmware-11222011-0244/03:52
wpwrakhmm, i think i can clean up all the scope/LA debugging stuff quite a bit if i just route signals to J21 and pick them up there with some nice connector and a reasonable cable03:57
stekernFWIW, ISE P&R supports multithreading, command line switch; -mt 406:36
xiangfustekern, thanks.07:14
xiangfustekern, will try to enable this next build :)07:19
wpwrakstekern: aaah, nice. thanks ! let's see how many years of my life it'll save ...08:05
wpwrakhmm, is there a "standard" makefile variable for things like -j ?08:05
xiangfuthere are : .NOTPARALLEL08:20
wpwrak"This current release of ISE limits the number of cores used by the Placer to 2.  Setting -mt to 2." ;-(08:20
xiangfu13.2?08:20
wpwrak13.308:25
wpwrakNOTPARALLEL sounds like the opposite :)08:26
xiangfuyes.08:27
xiangfuthere is on opposite for -j :)08:27
xiangfus/on/only08:28
wpwrakhmm, seems to be just as slow as before :-(08:36
wpwrakwith -mt 4 on map and par: real    10m39.300s user    11m35.040s08:38
stekernmaybe they just added that command line switch to shut up users complaining about no parallel par support ;)08:47
lekernel__yes, multithread map/par is lousy10:15
wpwrakwithout -mt 4: real 10m54.634s user 10m48.300s10:44
wpwrakstekern: your theory seems quite plausible :)10:45
GitHub40[milkymist] sbourdeauducq pushed 2 new commits to master: http://git.io/o4FzUA10:59
GitHub40[milkymist/master] connect the dependency between softusb and libhal, add libs dependency to bios - Xiangfu Liu10:59
GitHub40[milkymist/master] Cleanup BIOS makefile - Sebastien Bourdeauducq10:59
lekernelmwalle: 4'b10000 ?11:01
GitHub59[milkymist] sbourdeauducq pushed 11 new commits to master: http://git.io/vxO6bQ11:13
GitHub59[milkymist/master] sysctl: change offsets and new frequency register - Michael Walle11:13
GitHub59[milkymist/master] sysctl: new debug control register - Michael Walle11:13
GitHub59[milkymist/master] monitor: introduce write lock - Michael Walle11:13
GitHub60[milkymist] sbourdeauducq pushed 1 new commit to master: http://git.io/ovhNrA11:19
GitHub60[milkymist/master] software: remove redundant clk_frequency - Sebastien Bourdeauducq11:19
mwallelekernel: good catch ;) thanks11:22
qi-botThe Firmware build was successfull, see images here: http://fidelio.qi-hardware.com/~xiangfu/build-milkymist/milkymist-firmware-11222011-1159/13:04
lekernelwpwrak: ever tried matplotlib?14:01
lekernelbetter than gnuplot imho and directly accessible from python14:01
wpwrakhmm, don't think i tried it. i'm reasonably familiar with the gnuplot language, so i don't mind using it14:03
wpwraka bit annoying that verilog doesn't treat (a, b, c, ) as equivalent to (a, b, c). one more thing to learn to copy from C :)14:05
wpwraka verilog question: i tried to connect rx_pending to an i/o pin. my first attempt was to use a new net name in common.ucf, then pass it down the hierarchy into softusb_sie.v, where i "exported" rx_pending. this gave me a warning because i had re-declated rx_pending (as port vs. the previous register), but it worked14:23
wpwraknext, i tried to leave everything in its original state but declared the pin as  NET "usb/sie/rx_pending" LOC = K16;14:24
wpwrakthis got me a warning that it couldn't be done because "those design objects do not contain or drive any instances of the correct type."14:25
wpwrakand indeed, this one doesn't work14:26
wpwraki think the path i used is correct. so what would be a clean way for making such a "tap" ? can i just share the output of the existing register or do i have to introduce a register, explicitly assign to it, etc. ?14:29
wpwrak(which may change the timing)14:29
lekernelI don't think you can connect internal nets to I/O pins with such an UCF constraint14:35
lekernelyou have to propagate the signal into the hierarchy up to system.v14:35
kristianpaulindeed, and the propagate fun begin...14:36
lekernelmaybe you can hack it by instantiating an OBUF, but I have not tried14:36
kristianpaulthere is not  JTAG tap controler or such?14:39
kristianpaullet see..14:39
wpwrakmmh. propagating sounds messy.14:40
wpwraklet's see if i can "clone" it into a wire14:40
lekernelyou can define a new output x and use "assign x = rx_pending;"14:41
lekernelor try the OBUF hack with something along the lines of OBUF foo(.I(rx_pending)); and the UCF constraint you tried earlier14:42
qi-botThe Firmware build was successfull, see images here: http://fidelio.qi-hardware.com/~xiangfu/build-milkymist/milkymist-firmware-11222011-1405/14:55
wpwrakin terms of changes, the two seem equivalent ?14:57
wpwraklets try assign ...14:59
wpwrakassign in system.v: "Signal <rx_pending> is used but never assigned." (assign dbg = usb.sie.rx_pending;)15:33
wpwraki wonder if it would tell me if i mistyped the name. or maybe that's just a warning ?15:33
wpwraklet's see15:34
wpwrakno, it does tell15:34
wpwrakassign, version 2: assign in softusb_sie.v, pick it out from there from .ucf15:37
stekernwpwrak: iirc ise does not want to understand such constructs15:38
stekernusb.sie.rx_pending, that is15:39
stekernsimulation tools usually does (at least modelsim and icarus)15:40
wpwrakmy verilog book claims they're perfectly valid15:41
wpwrakand even xilinx documentation says .ucf is fine with pa/th/s15:41
stekernise obviously doesn't always play by the books :)15:41
wpwraksigh15:41
stekernfor pin mappings? pa/th/s does work for timing constraints etc15:43
wpwraknow i put assign dbg = ...; into softusb_sie.v: NET "usb/sie/dbg" not found.15:44
wpwraklet's try that OBUF hack15:44
wpwrakstekern: i guess all constraints are the same, no ? syntax is gives as NET "full name" constraint;15:46
wpwraksame error, NET "usb/sie/dbg" not found15:48
stekernyes, syntax is the same, but allowing to pin map signals not present in the top level module is not something I would expect to work15:52
wpwrakwhy not ? it's just a net name15:54
wpwraknet is net, no ? i mean, the whole build is on the whole design too. no hierarchical "linking", where nets could indeed be elimitated15:55
stekernyes, I don't think about it as technical impossible15:56
stekernapart from debug purposes I wouldn't want to do it neither15:57
wpwrakhmm, all those "warnings" about fairly serious problems suggest that verilog, or at least xilinx's implementation of it, doesn't exactly share python's obsessive-compulsive concern for neatness :)15:59
wpwrakfun fact: NET "usb/sie/dbg" ... causes an error because it can't find the object16:00
stekernwpwrak: that's what VHDL is for... :)16:00
wpwrakNET "usb/sie/rx_pending", where rx_pending is declared one line above the "dbg", does complain about mismatched type16:01
wpwrakso it seems whether it can find it or not depends entirely on the purpose - if it's to produce an error, it can find it with disdainful ease. if it's to make things work, no way.16:02
wpwraklet's try a variant ...16:04
stekernis dbg a reg or wire?16:09
wpwraka wire. with a reg, it complains that it's the wrong type.16:10
kristianpaulnah thats not a language problem, just all junk of non-free software that claim to works..16:10
wpwrakwith a wire, it doesn't find it.16:10
kristianpaulyou are doing the assign in the top module right?16:12
kristianpauli mean16:12
wpwraki tried tht. didn't work. then i sent it to the bottom. doesn't work either.16:12
kristianpaulyou need to propagate from the usb softcore the the top16:12
wpwrakthat's what i'm trying to avoid :)16:12
kristianpaulsure in the botton will not work i think16:12
kristianpaulwpwrak: you cant !! at least with assigns..16:12
wpwraki don't want to have to "bubble" things through intermediate layers. it's for debugging. so changing a lot of files is BAD.16:13
kristianpaulbut only way, at least that OBUF thing works..16:13
wpwraki tried OBUF at the bottom but that didn't work either16:14
kristianpaulso no choice16:14
wpwrakhaven't tried OBUF at the top, though16:14
kristianpaul"you can include test point in all designs is just matter of used to it"16:14
wpwrakmmh ?16:14
kristianpaultest points in the top and the route the the core you need16:15
kristianpaulyou dont need to change lots of files, because you already include then (testpoints) ;-)16:15
stekernbut it's just insane that mod1.mod2.signal doesn't work16:16
kristianpaulindeed16:16
stekernin that sense alteras signal probe is "good", it lets you probe signals wherever16:16
wpwrakwhat does OBUF exactly do ? declare an output port on the current module ? create a global output port ?16:17
wpwrakstekern: sounds just like what i'm looking for :)16:17
Action: kristianpaul looks lekernel 16:17
wpwrakstekern: J21 could be an excellent debug port if it wasn't too hard to route signals there16:18
wpwrakusing J21 wuold have numerous advantages over attaching probes to various points in the system, including: 1) easy access, 2) possibility to make an even more convenient adapter board, 3) short ground loop (ringing), 4) no contamination of original signal by probe16:19
wpwrak(adapter board) e.g., with small coaxial connectors to attach a scope. or a header for LA probes16:21
kristianpaulanyway if we want something portable, model some Test Points in verilog is not bad idea at all..16:24
kristianpaulor use chipscope.. :-S16:24
wpwrakwhat's also unpleasant about "bubbling up" is that each change, if made at the end of the parameter list, does in fact affect two lines: the line where the probe signal is added and the line above it, which gets a comma16:33
kristianpaulyeap..16:34
wpwrakOBUF doesn't create a global port. just tried that.16:35
kristianpaul..16:35
wpwraksigh. so bubble it is. let's do it at least without "warnings".16:36
kristianpaulbut wait IFDEF and such may help, so you can use the define tap16:36
kristianpaulzero warnings? :-)16:36
kristianpauls/tap/enable_tap16:37
wpwrakyeah, sure. make the code REALLY messy ;-)16:39
kristianpauli dont said the contrary :-)16:40
stekernwpwrak: put your "bubble" topmost, then you don't need the extra comma at least16:42
wpwraklekernel: by the way, here is a first hint at trouble with the USB data path: http://downloads.qi-hardware.com/people/werner/tmp/usb-D15rx_pending-100ns.png16:43
wpwrakstekern: ugly :) like  ", my_stuff"  would be. it's hard to be a perfectionist ...16:43
stekernhehe, yeah16:44
wpwraklekernel: this time, i used the LA of the mighty rigol to monitor rx_pending. D15 shows that it can be on for a pretty long time. up to about 500 ns.16:44
wpwrakand that's just the time until we grab the last byte of the packet. without any processing.16:45
wpwrakso this eats already about 200 ns from the 540-1300 ns time budget until the ACK timeout.16:47
wpwrak540 ns if we aim for full compliance, even if hubs are added16:47
wpwrak1300 ns if we just want to survive in a best-case scenario16:48
wpwrakthere may also be a rx_pending vs. EOP race. e.g., what if the following sequence of events happens ? 1) test for RX. 2) byte finishes and rx_pending is set. 3) eop is detected. 4) test for EOP. we may just be slow enough that this could happen. haven't checked yet if hw suppresses signaling of EOP while rx_pending is set, though16:50
wpwrakok, bubbled. now the diagnostics are more friendly16:55
wpwrakand it even works :)16:58
wpwrakalso interesting: http://downloads.qi-hardware.com/people/werner/tmp/usb-D15rx_pending-dur510ns.png16:58
wpwrakthis is with a duration trigger: trigger only if rx_pending was high for > 510 ns.16:59
wpwrakthis happens irregularly, at about 1 Hz long-term average17:00
wpwrakor maybe 2 Hz17:00
wpwrakwhat's interesting here is that rx_pending rises quite early in the last bit. this suggests that the sample clock may indeed be a little early17:00
lekernelwpwrak: an alternative to "bubbling" is editing the FPGA manually19:38
lekernelhttp://www.youtube.com/watch?v=wwkGmDaa4oM19:38
wpwrakamazing. that ought to be rather useful for reverse engineering :)19:56
lekerneloh, there's better than that: xdl19:59
wpwrakah, i see :)20:00
wpwrak"ironically, this [error] message tells us that everything is okay" ;-)20:06
GitHub14[flickernoise] sbourdeauducq pushed 1 new commit to master: http://git.io/vCeCaA20:42
GitHub14[flickernoise/master] compiler: load images - Sebastien Bourdeauducq20:42
wpwrakgrr. LV3 got stopped at customs :-(21:34
Artyomkristianpaul: Do I understan right that MM executes program from nor-flash? But keeps all the data (program variables) in SDRAM? Isn't it slow to execute program from slow flash-memory?21:45
Artyom(I watched system.v in rtl directory and linker.ld in bios directory)21:47
ArtyomOr processor cache works very efficient in this case?21:48
kristianpaulvery good question22:04
kristianpauli was sure just few programs we're executed from flash, bios for example22:04
kristianpaulArtyom: you menan for the tdc-core?22:05
Artyomno, I wrote about MM bios22:05
ArtyomYou gave the answer :)22:06
Artyomin demo directory, according to the linker.ld program is executed from RAM22:07
ArtyomSDRAM22:07
kristianpaulyes loaded to ram22:08
ArtyomBut then I would like to ask: How is demo program can be run after booting bios? With the flterm?22:08
kristianpaulyes22:09
kristianpaulflterm load it to bios and bios  load it to ram and executed it i think22:10
kristianpaulflterm is menthod for uart, there are also other methods like boot from network (tftp boot) and memory cards22:11
Artyomrunnig SDRAM becomes the most important task... ;)22:13
Artyomthanks for your help Kristianpaul :) time to sleep for me. bye!22:13
kristianpaulyou could, flterm all you need22:16
kristianpaulah well sdram support too ;-)22:16
kristianpaulbut that i think was solved in milkymist casrlos port22:16
kristianpauland load bios in a block-ram like in the tdc-core or papilio board fork22:18
qi-botThe Firmware build was successfull, see images here: http://fidelio.qi-hardware.com/~xiangfu/build-milkymist/milkymist-firmware-11222011-2142/22:31
GitHub147[linux-milkymist] mwalle pushed 3 new commits to master: http://git.io/UHPCHQ23:28
GitHub147[linux-milkymist/master] lm32: update driver for new uart core - Michael Walle23:28
GitHub147[linux-milkymist/master] milkymist_uart: don't restart tx - Michael Walle23:28
GitHub147[linux-milkymist/master] milkymist: new interrupt map - Michael Walle23:28
mwallelars_: serial should work now23:29
mwallelars_: www.walle.cc/initramfs.gz triggers the NULL pointer bug very often23:30
mwalleeither right after userspace is started or on multiple ls invocations23:31
--- Wed Nov 23 201100:00

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