#milkymist IRC log for Monday, 2012-05-28

wolfspraulstekern: thanks for chiming in on the migen/next-gen discussion!05:42
wolfspraulI think we have a pretty nice round of thoughts and ideas, not bad05:43
wolfspraulI vaguely remember some plan of trying an openrisc core in the milky soc, do you still have that plan?05:43
stekernyes, I've got the BIOS up and running on an older milkymist soc (non -ng)05:44
stekernit was a while ago since I last tinkered with it, other projects have came in between, but I still got my m1 on my work desk, so it is by no means "drawered" ;)05:46
stekernactually, the project in between isn't completely unrelated, I'm working on a openrisc llvm backend, and part of what got me interested in looking into it was the ongoing work on llvm-lm3205:59
wolfspraulok, nice06:04
wolfspraulthat sounds like we can be hopeful there will be some completion and realization about the openrisc/milkymist marriage one day06:04
wolfspraulanything we can learn or use/reuse from openrisc is probably a good thing06:05
wolfspraulkeep us posted :-)06:06
stekernI will06:08
wpwrakstep 1: get openrisc to run on m1. step 2: make m1 multicore with lm32. step 3: convert one core to openrisc. step 4: brag about it in public. step 5: see if anyone can come up with an explanation why such a thing would make sense ;-)06:13
stekernisn't the generic answer to step 5: "Because we can!" ;)06:18
wpwrakthat's the fallback answer :)06:19
stekernmore seriously, milkymist switching to openrisc would make sense, it would lift some weights of the milkymist projects shoulders; we've got an upstream linux port, people working on the gnu toolchain (following upstream), no lattice people boosting about them being "official maintainers" ;)06:24
wpwrakhow do the two compare in terms of speed, size, code quality ?06:25
stekernbut, a lot of effort has been made in the milkymist project on the lm32, I kind of dislike the idea of pulling the mat from under the feets of them06:25
wpwrakdoes openrisc have an mmu ?06:26
stekernthe or1200 implementation has one, yes06:26
stekernthe biggest problem is that the or1200 implementation kind of "sucks"06:27
Jiaor1200's insns code is suck06:28
stekernbut that is being worked on with this effort of a new implementation (but that doesn't have an mmu yet)06:28
wpwrakit seems to have quite a fan base. two people saying it sucks, within seconds ;-)06:29
wpwrakso it looks like somthing that will get back and forth for a while longer before it's really comparable06:30
stekernopenrisc and lm32 ISA is very similar06:30
Jialm32 insns code is more clear, like mips.06:30
Jiathe same at the other side.06:30
Jiabut lm32 has no MMU06:31
wpwrakFallenou: did you hear that ? :)06:31
wpwrakwho do they compare in terms of gate count and performance ?06:33
stekernor1200 and lm32? or the new implementation and lm32?06:34
wpwrakbest_of_openrisc vs. lm3206:35
stekernthe new implementation and lm32 is about comparable in terms of gate count and fmax06:36
stekernJia: what sucks?06:37
Jiastekern: opcodes/or32-opc.c06:38
JiaAAAAA BBBBB CCCCC06:38
wpwrakstekern: why does the or1200 rewrite drop the mmu ? it is just a way of structuring the work (e.g., do without mmu first, add mmu soon thereafter) ? or may the mmu not come back at all ?06:40
stekernwpwrak: well, it's a complete rewrite, so it didn't even have caches (until I helped out implementing them)06:41
stekernso it will come in time06:41
wpwrak(caches) ;-)06:42
wpwraksounds as if it'll take a bit to complete and mature06:42
wpwrakbut of course, when done, it could be quite attractive06:42
stekernyes, most definetely will take time to mature06:43
stekernJia: you mean how the bits in the instructions are layed out? yeah, that is a bit messy06:44
wpwrakpity we don't have any decent time machine. then we could avoid doing lm32-specific work if the 2014 edition of or1200 is clearly better for our needs06:44
wpwrakthere are no ugly instruction sets. except for PIC :)06:44
wpwrakthat one is so evil, it simply absorbs the entire ugliness of the universe06:45
stekernI've managed to avoid PICs for the most of my life (apart from one project) ;)06:45
wpwrakwhen i started to experiment with MCUs, i began with PIC. in assembler. the good thing about such a start is that no matter what happens later, it can only get better :)06:47
stekernkind of my story too, but I found AVRs early enough to ditch PICs after that first project ;)06:49
stekern(2014 edition) I can smell the sarcasm in that ;) but I agree, lm32 is probably the still the right choice for the project (for the time being)06:53
wpwrak(2014) do you think it'll be reliably usable and with a full feature set (i.e., MMU) sooner ? especially testing and optimizing may take a bit06:54
wpwrakanyway, time to suspend. thanks for the openrisc infos ! worth keeping an eye on06:57
stekernhard to tell, time will show, but we're working on it ;)06:58
stekernsuspend tight ;)06:59
Fallenouwpwrak: hehe I just read, sounds like for now lm32+mmu would be the killer couple !10:57
FallenouI thought about how we could reduce the penalty of flushing the MMU TLB during scheduling()10:58
FallenouFor things that have to be fast we could use one process and multiple threads :)10:58
Fallenouyou don't have to flush MMU TLB for switching between threads10:58
Fallenousince everything is in the same virtual address space10:59
Fallenouit would be a way of taking the benefits of MMU protection to protect against other processes (DHCP ? shell ? other things ?) but keeping for instance flickernoise "reactive"10:59
Fallenouanyway, just a thought, in case there is a noticeable slowdown caused by linux scheduling (flushing and reloading MMU TLB)11:01
Fallenoureloading MMU should be done in a lazy way I guess (only on page faults) which could help to increase performance too11:02
lekernelFallenou: yes, by all means, announce the mmu commits here12:49
Fallenouok !13:00
Fallenoua few CPUs I just unplugged from their old socket : http://sionneau.net/old_computers/cpu/DSC01897.JPG :' RIP my old computers13:31
Fallenoulekernel: on my 486 motherboard there was 5 SRAM DIP chips , what do you think they were there for ? ( http://www.datasheetcatalog.com/datasheets_pdf/W/2/4/5/W24512AK-15.shtml )13:31
Action: Fallenou is just curious13:32
lekernelcache memory13:46
Fallenouexternal cache memory for the 486 cpu ?13:48
lekernelI remember those from syster hack :) with a mach130 cpld and a 68hc1113:48
lekernelold times13:48
lekernelyes13:49
Fallenouhehe ok13:49
Fallenouit seems to be still valid chips13:49
Fallenoucontains 64 Ko which is not ridiculous13:49
Fallenouand 1 cycle access, and quite fast :)13:49
lekernel15ns is pretty slow13:49
Fallenoufor an external memory ?13:50
lekernelby today's standards13:50
Fallenouah yes13:50
Fallenoucompared to DDR1/2/3 and such13:50
lekernelwell, yeah, modern SRAM can be 7ns or less13:50
Fallenouok =)13:50
lekernelit's a pity the syster hack schematics aren't online... those were really nice, especially for their time13:50
lekernelyou had to download them from a BBS at 9600bps :)13:52
Fallenouopen source computer ?13:52
lekernelpirate TV decoder13:52
Fallenouoh ok13:52
lekernelhttp://en.wikipedia.org/wiki/Nagravision#Analog_system13:53
lekernelso this thing used the SRAM chips in combination with the CPLD to store those 32 lines13:54
Fallenouahah nice13:55
lekernelthe thing also had a built in code breaker, that would take a few minutes and then store the result in the supercapacitor-backed main (and slower) SRAM chip of the 68HC1113:56
FallenouI think the off chip sram was the L2 cache, L1 was on-chip14:07
Fallenoufor the i48614:07
lekernelaha! found it14:08
lekernelhttp://web.archive.org/web/20010613073002/http://eurosat.com/salp/schema/nag-sch.pdf14:08
GitHub15[milkymist-ng] sbourdeauducq pushed 2 new commits to master: http://git.io/QmDDNQ15:30
GitHub15[milkymist-ng/master] software/libbase: more file decls in stdio - Sebastien Bourdeauducq15:30
GitHub15[milkymist-ng/master] software/libbase: malloc family decl in stdlib - Sebastien Bourdeauducq15:30
wolfspraulare those links still up-to-date? http://www.milkymist.org/fpgatools/15:33
wolfspraulI was trying to look at the llhdl sources but couldn't find them, github gives me a 40415:33
wpwraklekernel: have you seen my comments about monitors with built-in touch screens ? there seem to be some quite decent models on the market now, mainly by iiyama. that should be a nice platform to develop your new gui and the things underneath.15:34
kristianpauloh15:35
kristianpaulgone !!15:35
kristianpaul(llhdl)15:35
kristianpaullets see if i still have local copy..15:35
kristianpaulphew15:35
wpwrakhere's a copy. not sure how up to date, though: https://github.com/errordeveloper/llhdl15:39
kristianpauli dont find mine..15:41
Action: kristianpaul sigh15:41
wolfspraullet's get word from lekernel first15:45
kristianpaulplease :)15:49
lekernelyes, the errordeveloper copy looks up to date15:53
wolfspraulthe links on milkymist.org point to a 404 page?15:53
wolfspraulis that on purpose?15:53
lekernelno15:53
wolfspraulhow about antares?15:54
lekerneljust an oversight15:54
wpwrakdid you rename it ?15:54
wpwrak(on github)15:54
lekernelno, deleted. if I were to continue working on it, I'd write it in a different way anyway.15:55
wolfspraulah? are you serious? and you mean until then you better don't want anybody else read the sources that were published so far?15:56
wpwrakwould have been more polite to announce that deletion a bit in advance15:57
wolfspraulshould we link milkymist.org to the errordeveloper copy?15:57
wolfspraulhow about antares?15:57
wpwrakit's not as if the secret police would descend on you if it sat there for a few weeks longer15:57
lekernel(annoucing) sorry about that. didn't think too many people cared anyway.15:59
kristianpaulcan yo re-publish it? at least for achiving porpuses a tar would be ok..16:00
kristianpauls/yo/you16:00
lekernelok. but then you take care of it :)16:00
kristianpaulwell, for now i care about  read the sources16:01
wolfspraulyes cool, bring it back please that would be great. and the links on milkymist.org will work again too :-)16:02
lekernelkristianpaul: are you really reading that much source code?16:02
kristianpauli was once  i wanted to know how to make the LUT6 work for spartan316:03
wpwrakit can be useful reference material for someone else who wants to work in that direction. every bit helps :)16:04
kristianpaulyup16:05
lekernelin the open source community, no one wants to work in that direction. even open-CPUs are obscure things.16:05
wpwraknobody does it and all agree it would be pointless. until someone does ;-)16:05
lekernelotherwise that linux port would be long done, among other things16:05
lekernelinstead, people rush to port their software to the rpi16:05
wolfspraulwell, I just thought about it today16:06
wpwrakyou mistake priorities for lack of interest16:06
wolfspraulsay you have an rpi + usb webcam16:06
wolfspraulhow hard is it to port milkdrop to it, and get it to do m1-like effects?16:06
wolfspraulthe hardware costs 30 USD rpi + 20 USD webcam16:06
wolfspraulI think it could beat m1 on many angles?16:07
lekernelyou're just making my point16:07
lekerneland this is why I want distinctive hw features, and no generic features like USB that people take for granted16:09
wolfspraulwell, seriously? I think maybe that would be easy to get to work and performance-wise should not be too bad either16:09
wolfsprauland it would most likely exceed the m1 in many many tech specs, resolution, bit depth, extremely better usb, etc. etc.16:09
lekernelgive me broadcom's budget ...16:10
wolfspraulI don't know, won't try. but somehow thinking about it I do believe it could just work. apt-get install milkdrop? is that in debian?16:10
wolfspraulmaybe even multiple webcams?16:10
Fallenourpi is not for developping16:13
Fallenouit's just a portable desktop16:13
Fallenoumini desktop16:13
Fallenouyou don't have access to the SoC datasheet, therefore you can do nothing with it in term of development16:13
wolfspraulsure, but maybe one could run m1-like effects on it, and even beat m1 on a lot of aspects?16:13
Fallenouyou can just boot it up and run your debian16:13
wpwraki think there's something a bit more pc-like from via, for about USD 5016:13
wpwrakFallenou: broadcom released the data sheet for the soc, with information on most of the subsystems16:14
Fallenouin term of jitter/latency I'm not that sure about what the soc would do16:14
Fallenouwpwrak: oh really ? OK I didn't know16:14
FallenouI'm wondering, why are FPGA so slow ? I don't see any softcore operating at more than 150 MHz :/16:16
Fallenoufor instance Leon3 : 125 MHz as a softcore | 400 MHz as a 0.13 um ASIC16:17
FallenouLeon4 : 150 MHz as a softcore | 1.5 GHz on 32 nm ASIC16:18
kristianpauldistinctive hw features, but what about software?16:23
kristianpaulnot all is about hw :)16:23
wolfspraulok so for the time being we can just assume that it 'may' well be possible to implement m1-like features with rpi+webcam16:24
wpwrakFallenou: here's the broadcom data sheet: http://www.element14.com/community/docs/DOC-43016/l/broadcom-datasheet-for-bcm2835-soc-used-in-raspberry-pi16:24
wolfspraulif it's possible, it will most likely outperform m1 in a number of areas16:24
kristianpaulprojectm is in debian yes wolfspraul16:25
wolfspraulthat needs to be said openly and honestly, not in any vague way16:25
wpwrakironically, i couldn't find it via broadcom.com16:25
lekernelwolfspraul: it's certainly possible. you'd have more latency, though.16:25
kristianpaulFallenou: yes hw development, custom cores and video acelaration, but we cant forget software as well16:26
wolfspraulI would compare that when it's working16:26
wolfspraulelement14 is a large chinese distributor16:26
wolfspraulmaybe they just upload docs? :-)16:26
wolfsprauland broadcom is pulling their hair out over the uncontrollable chinese :-)16:26
kristianpaulhe16:26
wolfspraulany FAE in china will just copy/paste entire trees full of nda/confidential documents anyway16:26
wolfspraulto anybody who buys even 3 chips for 10 USD16:26
wolfspraulfae or salesman16:27
wpwrakwolfspraul: that may just be a cache. i think the release was more official. but my quick search didn't turn up the original posting / article16:28
wolfspraulI think I read something from the rpi project that they managed to get some datasheet out of broadcom for release16:28
lekernelwolfspraul: still don't like the mirteo? another area where it helps. :)16:28
wolfspraulwhere you need to know that rpi *is* broadcom marketing16:28
kristianpaulFallenou: so wen need to choose our targets very well, so still a gap to innovate in hw as well16:28
kristianpauli think..16:29
wolfspraulyou can't expect to fool people multiple times16:29
wolfspraulmaybe try a new name first :-)16:29
wolfspraulI think m1 is on good track and with the things we have learnt and are learning we will figure out how to sell it successfully16:30
wolfspraulI have no problem at all understanding the excitement behind rpi though16:30
wolfspraulm1 is pretty lousy on almost all tech specs I can think of16:30
wolfspraulcompared to other 'modern' tech16:30
lekernelbut the mirteo won't.16:30
wolfspraulso? the people we have found need to see other values16:30
wpwrakah, that's why it's not on broadcom.com: http://www.raspberrypi.org/phpBB3/viewtopic.php?f=63&t=3265&p=43494&hilit=data+sheet#p4349416:31
wpwrakit's "official", though16:31
wolfspraulI rather fix m1 bugs16:32
kristianpaulm1 either, still have dmx16:32
kristianpaulhave you qoute a dmx controller recently? :)16:32
wolfspraulI don't believe the (many) shortcomings we have started to understand on m1 wouldn't reappear in later products again16:33
wolfspraulah god, of course16:33
wolfspraulm1 is full of features that are started, full of bugs, never seriously fixed or marketed or tested or anything16:33
wpwraklekernel: i think a monitor+touch combined with the existing M1 would be a much quicker way to a new user experience16:33
Fallenou+116:34
Fallenoustep by step :)16:34
wpwrakthe blocks you put on the reactable seem more an obstacle than a feature to me. sure, they're a novelty effect, but you should be able to just do the same with only a touch screen16:34
wpwrakyou can still aim for star trek aesthetics. they look good, even today :)16:35
Fallenoubut the novelty effect could affect sells :)16:35
Fallenouthere is little difference sometimes between a product that sells and a product that does not sell16:35
wpwrakFallenou: yes, until VJs start complaining that they lost blocks and such16:35
Fallenousometime it's just some design stuff16:35
Fallenoucolour, texture16:35
Fallenouor just the brand =)16:35
Fallenouif you do a tablet, you get compared to Apple ipad etc16:36
Fallenouand you will never win16:36
wpwrakconsider the mobile VJ who bring the equipment to the club. i don't thing the idea of carrying a bag of essential expensive little blocks is very appealing to them.16:36
Fallenouif you do a table with objects, you get compared to what ? :)16:36
Fallenouto nothing16:36
wolfspraulI believe milkymist as a platform has legs. if we fix some of the many many bugs, it will find its way to more happy users.16:36
Fallenouyou're just cool16:36
wpwrakeach morning, they get to count now many they have lost. crawl on the floor, etc.16:36
wpwrakand every once in a while, the one they would need just now (during the show) can't be located.16:37
Fallenouindeed it's a problem16:37
wpwraknone of these issues happen if it's just a screen16:37
Fallenouyou could think of a rf signal that makes them blink and play a loud sound16:37
Fallenoulike some gadget not to lose your keys16:37
wpwrakplus, you can get industrially made rugged screens.16:37
Fallenou(rf signal, to please wolfspraul :D)16:37
wpwrakas if you would hear them beep for their mother while the music is on. you must visit very quiet clubs ;-)16:38
Fallenouahah16:38
Fallenousearch for them after the club is closed16:38
Fallenouwhile packing16:38
Action: kristianpaul wonder how famous a reactable is now that the tables is on its rush 16:38
wpwrakand you've just made them quite a bit more expensive. now they need to store offline power, too.16:39
lekernelwpwrak: http://worrydream.com/ABriefRantOnTheFutureOfInteractionDesign/16:39
kristianpaulwhne i met the reactable 4 years ago was intersting, but now will call same atention?16:39
Fallenouindeed, it was just a random thought, maybe not a good idea :/16:39
kristianpaulbut definetelly we need a touch interface that can be compated with ipads..16:40
wpwrak(monitor+touch) i find the idea of having a separate control surface very appealing. we've discussed that before. and the reduction from a tablet to a monitor is a welcome simplification. so i like the mirteo idea that far.16:41
wpwrakbut mirteo adds a lot more complications. things that most likely work against it.16:42
kristianpauli agree with separate16:42
lekernelright now the only sensible argument against it is the lost objects16:42
lekernelany more?16:42
wpwrakand since you need some sort of mounting frame anyway, you can hide any features of m1 you don't like inside. don't want users to plug in usb ? just add a little wall. done :)16:42
wpwrakamount of work to get it to function reliably16:43
wpwrakalso, you want to redo m1 in the process. this increases the amount of work even more.16:43
lekernelif we drop all the pesky stuff (USB, ...) it's not that much work16:43
wpwraki don't think you believe that yourself ;-)16:43
lekernelI find the general M1 development could have been even more efficient16:44
wpwrakbesides, as i mentioned, you don't have to worry about things like usb16:44
wpwrakthe M1 would just be inside the frame16:44
wpwrakyou can hide or reveal whatever you feel comfortable with at that time16:44
wpwrakand if you change your mind. that's just a matter of cutting a new frame. half a day of carpentry.16:45
kristianpaullekernel: we do really need ddr3 and next xilinx chips _now_ to improve video out specs?16:46
kristianpaullekernel: anymore, yes, start over again :)16:47
wpwrakwe need better memory for 32 bpp AND higher resolution. it seems that m1rc3/m1r4 will be more than adequate for driving a secondary screen for control functions16:47
kristianpaulgood16:48
kristianpaulso the wall interface as an accesory to current m1 is what you propose right?16:48
wpwrakworst case, you'll need to make a little expansion board that adds another VGA out (for m1rc3). been there, done that (ubb-vga) :)16:49
kristianpaullol16:49
kristianpaul:)16:49
kristianpauland yes,16:53
kristianpaulwolfspraul still want a second screen? :)16:53
kristianpaulthat idea/request came from long before i remenber16:53
kristianpaulnow is the time it seems16:53
wolfspraulof course16:54
wolfsprauldigital16:54
wolfspraulmaybe with r4 we can drive both the vga & digital separately?16:54
wolfspraulbut it depends on how much sebastien focuses on m1 at this point and gets the whole migen power to i116:54
wolfspraulotherwise we have to backport and that may be slow16:54
wolfspraulbut we get to it, I think we have 2 screens on r416:54
wpwrak(multi-screen with m1r4) definitely. of course, not a lot of resolution, because already one 640x480 at 32 bpp outout will tax the system16:55
lekernelwhat about r5 with ddr3, -7 and dual video output?16:55
wpwrakbut a 1 bpp channel for the secondary display should be no problem16:55
wolfspraulsure16:55
wpwraklekernel: that would be a sensible evolution16:56
lekernelwpwrak: I think there might still be some bw left16:56
wpwrakeven better :)16:56
lekernelbut then there will be the compatibility problem with r516:56
wolfspraulr5 with -7 ddr3 etc would be great16:56
kristianpaulso,  we do really need ddr3 and next xilinx chips _now_ to improve video out specs?16:56
kristianpaullekernel: ^16:56
wpwrakm1r4 could still do the same with 1 bpp :)16:57
wolfspraulcompatibility will be a big issue, and at multiple layers of the system, but that's something we can help with I think16:57
lekernelwpwrak: but then software has to handle 1bpp16:57
wpwrakwell, there's no free lunch :)16:57
wolfspraulkristianpaul: those things go in parallel16:57
wolfspraulm1rc3 is not maxed out16:57
wolfspraulm1r4 not even made yet16:57
lekernelkristianpaul: no. -ng should already increase the bandwidth by 2x to 4x16:57
wolfsprauland m1r5 only in conceptional stage16:57
lekernelon the current m1 boards16:57
Fallenou2x 4x <= awesome :'16:57
kristianpaulwolfspraul: yes sure, i dont mind having a s-7 dd3 box _just_ for the full HD thing16:58
wolfspraulyeah16:58
kristianpaulFallenou: indeed :)16:58
wolfspraulif you can bring that to m1, or if we can (reasonably, that is practically) help, many people would be happy. well. some people :-) not as many as there are rpi users...16:58
wpwrakthe new gui will need quite a bit of work anyway. adding 1 bpp support should be a pretty minor item, compared to the rest16:58
lekernelwpwrak: I think the second fb could work at 16bpp16:59
lekernelmaybe 32 even16:59
wpwrakthat would be pretty amazing. of course, it may actually look its best with very few color. an austere style can be very appealing.17:00
lekernelwe're using 3 gbps atm, switching to 32 would make that 6, and -ng has up to 1017:00
kristianpaulwolfspraul: parallel indeed, but no drop one  effort and begin other from scratch :)17:00
wpwraksends a strong message of this being a tool that gets the job done17:00
kristianpaulbbl lunch17:00
wolfspraulenjoy17:00
Fallenoua framebuffer uses ram bandwidth quite efficiently, since it's always burst access17:01
lekernel-ng reorders ram transactions anyway to make them efficient most of the time :)17:01
Fallenouis there some case where reordering adds latency ?17:01
lekernelreordering always adds latency17:02
lekernelso it will make software a bit slower (though if the L1/L2 cache hit rate are high, only by a few percent at worse)17:03
lekerneland TMU/FB/video-in will be redesigned to cope with latency better17:04
Fallenouok17:05
lekernelthere are some experiments to do, like disabling reordering for transactions that emanate from software and schedule them for minimum latency17:05
lekernelI can try that, if it turns out that some performance-critical software code becomes memory-bound17:06
Fallenoulekernel: http://pastebin.com/767KifbS why don't I see my uart_write() ?17:21
Fallenouit seem to hand the SoC17:21
Fallenouhang*17:22
FallenouI guess it's blocked waiting for some ack/irq from uart core17:22
Fallenoubut can't figure out why17:22
Fallenouam I not setting it up to polling mode ?17:22
Fallenou(just look at the main() )17:23
lekernelhmm iirc there's no polling mode17:23
lekernelit always needs irqs17:23
Fallenouerr my pastebin is wrong17:23
Fallenouit's not what I wanted to paste17:23
lekernelnevertheless I think I remember removing the polling uart code17:24
Fallenouhere is the content of my main() : http://pastebin.com/rAd43s0417:25
Fallenouoh17:25
Fallenoubecause now mmu activates itself upon interrupt/exception17:26
Fallenoubut for debug purposes it was usefull to be able to do printf(); without activating mmu17:27
lekernellet me check...17:27
Fallenouto ensure that MMU does not activates itself when I don't want to, I disabled IRQ in the bios C code17:27
Fallenoubut then indeed uart does not work anymore17:27
Fallenouok thanks17:28
lekernelnah, print should still work17:28
lekernelhttps://github.com/milkymist/milkymist/blob/master/software/libbase/uart.c#L9217:28
lekernelit's polling there17:28
lekerneldoes uart_force_sync() return?17:28
Fallenouok that's what I thought17:28
FallenouI could try to make a LED blink after uart_force_sync() to check17:29
lekernelI removed it in -ng but not in legacy17:29
lekernel(the polling)17:29
lekernelFallenou: why not try printing something immediately before and after force_sync?17:29
Fallenouusing uart_write() ?17:30
lekernelyour uart doesn't work at all? even while the mmu is still disabled?17:30
Fallenouor directly writting to uart register ?17:30
lekerneluart_write17:30
FallenouI think I tried and it did not write anything17:30
Fallenoulet me recheck17:30
Fallenouit does not write anything17:31
Fallenoubtw I am using regular bitstream, official milkymist one, without any MMU stuff17:32
lekernelis the uart cable correctly connected?17:33
Fallenouwhen I say "nothing", means nothing after SDRAM initialization text17:34
FallenouAll SDRAM initialization completed, boot continuing.17:35
Fallenouthis is the last thing I can see17:35
lekerneleven with milkymist.org/updates ?17:35
Fallenouwhat do you mean ?17:36
lekerneltry the known-good images17:36
Fallenouthe bitstream is the official one17:36
Fallenouthe bios is modified17:36
Fallenouhttp://pastebin.com/u4c62y2q <= this is working (writting F in uart)17:38
Fallenouhttp://pastebin.com/q50HPnS0 <= this is not17:41
lekernelcalling uart_init(); again will put you back into irq-driven mode17:44
lekernelyou should call it only once17:44
lekernelat the beginning of main17:44
lekernelbefore force_sync or anything else17:44
Fallenouoh right !17:44
Fallenouok working now :)17:45
Fallenouthanks !17:45
FallenouI can see "EF"17:45
FallenouI just moved uart_init() up17:45
GitHub13[milkymist-ng] sbourdeauducq pushed 4 new commits to master: http://git.io/xjY4Gw17:49
GitHub13[milkymist-ng/master] software/libbase: fix stupid mistake in limits.h - Sebastien Bourdeauducq17:49
GitHub13[milkymist-ng/master] software/libbase: use compiler-rt - Sebastien Bourdeauducq17:49
GitHub13[milkymist-ng/master] software/libbase: add strerror - Sebastien Bourdeauducq17:49
Fallenoutest_user_abort() seems not to work in polling mode17:54
Fallenouit's using readchar_nonblock()17:54
Fallenoueven if I enter ESC or Q it's booting from flash17:55
FallenouI will just remove the test I guess17:56
wpwrakwriting with polling still works ? that would be pretty essential for a lot of low-level work18:43
lekernelyes18:54
lekernelthough not implemented in -ng, but that wouldn't be the hardest thing to do when needed18:54
GitHub196[milkymist-ng] sbourdeauducq pushed 1 new commit to master: http://git.io/uUSx6w19:19
GitHub196[milkymist-ng/master] software/libbase/vsnprintf: treat %g as %f (temporary hack) - Sebastien Bourdeauducq19:19
GitHub52[misp] sbourdeauducq created master (+9 new commits): http://git.io/8vIyTg20:11
GitHub52[misp/master] Initial commit. fdlibm. - Sebastien Bourdeauducq20:11
GitHub52[misp/master] libm: rename fdlibm.h -> math.h - Sebastien Bourdeauducq20:11
GitHub52[misp/master] gitignore - Sebastien Bourdeauducq20:11
Fallenouhum readchar without interrupt seems tricky22:00
Fallenouthat would mean I would basically lose any character coming from the uart while I am not waiting for it doing while(UART_EVENT_REGISTER & EVENT_RX);22:01
Fallenougn8 !22:12
--- Tue May 29 201200:00

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