| wolfspraul | stekern: thanks for chiming in on the migen/next-gen discussion! | 05:42 |
|---|---|---|
| wolfspraul | I think we have a pretty nice round of thoughts and ideas, not bad | 05:43 |
| wolfspraul | I vaguely remember some plan of trying an openrisc core in the milky soc, do you still have that plan? | 05:43 |
| stekern | yes, I've got the BIOS up and running on an older milkymist soc (non -ng) | 05:44 |
| stekern | it 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 |
| stekern | actually, 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-lm32 | 05:59 |
| wolfspraul | ok, nice | 06:04 |
| wolfspraul | that sounds like we can be hopeful there will be some completion and realization about the openrisc/milkymist marriage one day | 06:04 |
| wolfspraul | anything we can learn or use/reuse from openrisc is probably a good thing | 06:05 |
| wolfspraul | keep us posted :-) | 06:06 |
| stekern | I will | 06:08 |
| wpwrak | step 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 |
| stekern | isn't the generic answer to step 5: "Because we can!" ;) | 06:18 |
| wpwrak | that's the fallback answer :) | 06:19 |
| stekern | more 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 |
| wpwrak | how do the two compare in terms of speed, size, code quality ? | 06:25 |
| stekern | but, 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 them | 06:25 |
| wpwrak | does openrisc have an mmu ? | 06:26 |
| stekern | the or1200 implementation has one, yes | 06:26 |
| stekern | the biggest problem is that the or1200 implementation kind of "sucks" | 06:27 |
| Jia | or1200's insns code is suck | 06:28 |
| stekern | but that is being worked on with this effort of a new implementation (but that doesn't have an mmu yet) | 06:28 |
| wpwrak | it seems to have quite a fan base. two people saying it sucks, within seconds ;-) | 06:29 |
| wpwrak | so it looks like somthing that will get back and forth for a while longer before it's really comparable | 06:30 |
| stekern | openrisc and lm32 ISA is very similar | 06:30 |
| Jia | lm32 insns code is more clear, like mips. | 06:30 |
| Jia | the same at the other side. | 06:30 |
| Jia | but lm32 has no MMU | 06:31 |
| wpwrak | Fallenou: did you hear that ? :) | 06:31 |
| wpwrak | who do they compare in terms of gate count and performance ? | 06:33 |
| stekern | or1200 and lm32? or the new implementation and lm32? | 06:34 |
| wpwrak | best_of_openrisc vs. lm32 | 06:35 |
| stekern | the new implementation and lm32 is about comparable in terms of gate count and fmax | 06:36 |
| stekern | Jia: what sucks? | 06:37 |
| Jia | stekern: opcodes/or32-opc.c | 06:38 |
| Jia | AAAAA BBBBB CCCCC | 06:38 |
| wpwrak | stekern: 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 |
| stekern | wpwrak: well, it's a complete rewrite, so it didn't even have caches (until I helped out implementing them) | 06:41 |
| stekern | so it will come in time | 06:41 |
| wpwrak | (caches) ;-) | 06:42 |
| wpwrak | sounds as if it'll take a bit to complete and mature | 06:42 |
| wpwrak | but of course, when done, it could be quite attractive | 06:42 |
| stekern | yes, most definetely will take time to mature | 06:43 |
| stekern | Jia: you mean how the bits in the instructions are layed out? yeah, that is a bit messy | 06:44 |
| wpwrak | pity 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 needs | 06:44 |
| wpwrak | there are no ugly instruction sets. except for PIC :) | 06:44 |
| wpwrak | that one is so evil, it simply absorbs the entire ugliness of the universe | 06:45 |
| stekern | I've managed to avoid PICs for the most of my life (apart from one project) ;) | 06:45 |
| wpwrak | when 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 |
| stekern | kind 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 bit | 06:54 |
| wpwrak | anyway, time to suspend. thanks for the openrisc infos ! worth keeping an eye on | 06:57 |
| stekern | hard to tell, time will show, but we're working on it ;) | 06:58 |
| stekern | suspend tight ;) | 06:59 |
| Fallenou | wpwrak: hehe I just read, sounds like for now lm32+mmu would be the killer couple ! | 10:57 |
| Fallenou | I thought about how we could reduce the penalty of flushing the MMU TLB during scheduling() | 10:58 |
| Fallenou | For things that have to be fast we could use one process and multiple threads :) | 10:58 |
| Fallenou | you don't have to flush MMU TLB for switching between threads | 10:58 |
| Fallenou | since everything is in the same virtual address space | 10:59 |
| Fallenou | it 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 |
| Fallenou | anyway, just a thought, in case there is a noticeable slowdown caused by linux scheduling (flushing and reloading MMU TLB) | 11:01 |
| Fallenou | reloading MMU should be done in a lazy way I guess (only on page faults) which could help to increase performance too | 11:02 |
| lekernel | Fallenou: yes, by all means, announce the mmu commits here | 12:49 |
| Fallenou | ok ! | 13:00 |
| Fallenou | a few CPUs I just unplugged from their old socket : http://sionneau.net/old_computers/cpu/DSC01897.JPG :' RIP my old computers | 13:31 |
| Fallenou | lekernel: 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 curious | 13:32 | |
| lekernel | cache memory | 13:46 |
| Fallenou | external cache memory for the 486 cpu ? | 13:48 |
| lekernel | I remember those from syster hack :) with a mach130 cpld and a 68hc11 | 13:48 |
| lekernel | old times | 13:48 |
| lekernel | yes | 13:49 |
| Fallenou | hehe ok | 13:49 |
| Fallenou | it seems to be still valid chips | 13:49 |
| Fallenou | contains 64 Ko which is not ridiculous | 13:49 |
| Fallenou | and 1 cycle access, and quite fast :) | 13:49 |
| lekernel | 15ns is pretty slow | 13:49 |
| Fallenou | for an external memory ? | 13:50 |
| lekernel | by today's standards | 13:50 |
| Fallenou | ah yes | 13:50 |
| Fallenou | compared to DDR1/2/3 and such | 13:50 |
| lekernel | well, yeah, modern SRAM can be 7ns or less | 13:50 |
| Fallenou | ok =) | 13:50 |
| lekernel | it's a pity the syster hack schematics aren't online... those were really nice, especially for their time | 13:50 |
| lekernel | you had to download them from a BBS at 9600bps :) | 13:52 |
| Fallenou | open source computer ? | 13:52 |
| lekernel | pirate TV decoder | 13:52 |
| Fallenou | oh ok | 13:52 |
| lekernel | http://en.wikipedia.org/wiki/Nagravision#Analog_system | 13:53 |
| lekernel | so this thing used the SRAM chips in combination with the CPLD to store those 32 lines | 13:54 |
| Fallenou | ahah nice | 13:55 |
| lekernel | the 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 68HC11 | 13:56 |
| Fallenou | I think the off chip sram was the L2 cache, L1 was on-chip | 14:07 |
| Fallenou | for the i486 | 14:07 |
| lekernel | aha! found it | 14:08 |
| lekernel | http://web.archive.org/web/20010613073002/http://eurosat.com/salp/schema/nag-sch.pdf | 14:08 |
| GitHub15 | [milkymist-ng] sbourdeauducq pushed 2 new commits to master: http://git.io/QmDDNQ | 15:30 |
| GitHub15 | [milkymist-ng/master] software/libbase: more file decls in stdio - Sebastien Bourdeauducq | 15:30 |
| GitHub15 | [milkymist-ng/master] software/libbase: malloc family decl in stdlib - Sebastien Bourdeauducq | 15:30 |
| wolfspraul | are those links still up-to-date? http://www.milkymist.org/fpgatools/ | 15:33 |
| wolfspraul | I was trying to look at the llhdl sources but couldn't find them, github gives me a 404 | 15:33 |
| wpwrak | lekernel: 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 |
| kristianpaul | oh | 15:35 |
| kristianpaul | gone !! | 15:35 |
| kristianpaul | (llhdl) | 15:35 |
| kristianpaul | lets see if i still have local copy.. | 15:35 |
| kristianpaul | phew | 15:35 |
| wpwrak | here's a copy. not sure how up to date, though: https://github.com/errordeveloper/llhdl | 15:39 |
| kristianpaul | i dont find mine.. | 15:41 |
| Action: kristianpaul sigh | 15:41 | |
| wolfspraul | let's get word from lekernel first | 15:45 |
| kristianpaul | please :) | 15:49 |
| lekernel | yes, the errordeveloper copy looks up to date | 15:53 |
| wolfspraul | the links on milkymist.org point to a 404 page? | 15:53 |
| wolfspraul | is that on purpose? | 15:53 |
| lekernel | no | 15:53 |
| wolfspraul | how about antares? | 15:54 |
| lekernel | just an oversight | 15:54 |
| wpwrak | did you rename it ? | 15:54 |
| wpwrak | (on github) | 15:54 |
| lekernel | no, deleted. if I were to continue working on it, I'd write it in a different way anyway. | 15:55 |
| wolfspraul | ah? 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 |
| wpwrak | would have been more polite to announce that deletion a bit in advance | 15:57 |
| wolfspraul | should we link milkymist.org to the errordeveloper copy? | 15:57 |
| wolfspraul | how about antares? | 15:57 |
| wpwrak | it's not as if the secret police would descend on you if it sat there for a few weeks longer | 15:57 |
| lekernel | (annoucing) sorry about that. didn't think too many people cared anyway. | 15:59 |
| kristianpaul | can yo re-publish it? at least for achiving porpuses a tar would be ok.. | 16:00 |
| kristianpaul | s/yo/you | 16:00 |
| lekernel | ok. but then you take care of it :) | 16:00 |
| kristianpaul | well, for now i care about read the sources | 16:01 |
| wolfspraul | yes cool, bring it back please that would be great. and the links on milkymist.org will work again too :-) | 16:02 |
| lekernel | kristianpaul: are you really reading that much source code? | 16:02 |
| kristianpaul | i was once i wanted to know how to make the LUT6 work for spartan3 | 16:03 |
| wpwrak | it can be useful reference material for someone else who wants to work in that direction. every bit helps :) | 16:04 |
| kristianpaul | yup | 16:05 |
| lekernel | in the open source community, no one wants to work in that direction. even open-CPUs are obscure things. | 16:05 |
| wpwrak | nobody does it and all agree it would be pointless. until someone does ;-) | 16:05 |
| lekernel | otherwise that linux port would be long done, among other things | 16:05 |
| lekernel | instead, people rush to port their software to the rpi | 16:05 |
| wolfspraul | well, I just thought about it today | 16:06 |
| wpwrak | you mistake priorities for lack of interest | 16:06 |
| wolfspraul | say you have an rpi + usb webcam | 16:06 |
| wolfspraul | how hard is it to port milkdrop to it, and get it to do m1-like effects? | 16:06 |
| wolfspraul | the hardware costs 30 USD rpi + 20 USD webcam | 16:06 |
| wolfspraul | I think it could beat m1 on many angles? | 16:07 |
| lekernel | you're just making my point | 16:07 |
| lekernel | and this is why I want distinctive hw features, and no generic features like USB that people take for granted | 16:09 |
| wolfspraul | well, seriously? I think maybe that would be easy to get to work and performance-wise should not be too bad either | 16:09 |
| wolfspraul | and it would most likely exceed the m1 in many many tech specs, resolution, bit depth, extremely better usb, etc. etc. | 16:09 |
| lekernel | give me broadcom's budget ... | 16:10 |
| wolfspraul | I 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 |
| wolfspraul | maybe even multiple webcams? | 16:10 |
| Fallenou | rpi is not for developping | 16:13 |
| Fallenou | it's just a portable desktop | 16:13 |
| Fallenou | mini desktop | 16:13 |
| Fallenou | you don't have access to the SoC datasheet, therefore you can do nothing with it in term of development | 16:13 |
| wolfspraul | sure, but maybe one could run m1-like effects on it, and even beat m1 on a lot of aspects? | 16:13 |
| Fallenou | you can just boot it up and run your debian | 16:13 |
| wpwrak | i think there's something a bit more pc-like from via, for about USD 50 | 16:13 |
| wpwrak | Fallenou: broadcom released the data sheet for the soc, with information on most of the subsystems | 16:14 |
| Fallenou | in term of jitter/latency I'm not that sure about what the soc would do | 16:14 |
| Fallenou | wpwrak: oh really ? OK I didn't know | 16:14 |
| Fallenou | I'm wondering, why are FPGA so slow ? I don't see any softcore operating at more than 150 MHz :/ | 16:16 |
| Fallenou | for instance Leon3 : 125 MHz as a softcore | 400 MHz as a 0.13 um ASIC | 16:17 |
| Fallenou | Leon4 : 150 MHz as a softcore | 1.5 GHz on 32 nm ASIC | 16:18 |
| kristianpaul | distinctive hw features, but what about software? | 16:23 |
| kristianpaul | not all is about hw :) | 16:23 |
| wolfspraul | ok so for the time being we can just assume that it 'may' well be possible to implement m1-like features with rpi+webcam | 16:24 |
| wpwrak | Fallenou: here's the broadcom data sheet: http://www.element14.com/community/docs/DOC-43016/l/broadcom-datasheet-for-bcm2835-soc-used-in-raspberry-pi | 16:24 |
| wolfspraul | if it's possible, it will most likely outperform m1 in a number of areas | 16:24 |
| kristianpaul | projectm is in debian yes wolfspraul | 16:25 |
| wolfspraul | that needs to be said openly and honestly, not in any vague way | 16:25 |
| wpwrak | ironically, i couldn't find it via broadcom.com | 16:25 |
| lekernel | wolfspraul: it's certainly possible. you'd have more latency, though. | 16:25 |
| kristianpaul | Fallenou: yes hw development, custom cores and video acelaration, but we cant forget software as well | 16:26 |
| wolfspraul | I would compare that when it's working | 16:26 |
| wolfspraul | element14 is a large chinese distributor | 16:26 |
| wolfspraul | maybe they just upload docs? :-) | 16:26 |
| wolfspraul | and broadcom is pulling their hair out over the uncontrollable chinese :-) | 16:26 |
| kristianpaul | he | 16:26 |
| wolfspraul | any FAE in china will just copy/paste entire trees full of nda/confidential documents anyway | 16:26 |
| wolfspraul | to anybody who buys even 3 chips for 10 USD | 16:26 |
| wolfspraul | fae or salesman | 16:27 |
| wpwrak | wolfspraul: that may just be a cache. i think the release was more official. but my quick search didn't turn up the original posting / article | 16:28 |
| wolfspraul | I think I read something from the rpi project that they managed to get some datasheet out of broadcom for release | 16:28 |
| lekernel | wolfspraul: still don't like the mirteo? another area where it helps. :) | 16:28 |
| wolfspraul | where you need to know that rpi *is* broadcom marketing | 16:28 |
| kristianpaul | Fallenou: so wen need to choose our targets very well, so still a gap to innovate in hw as well | 16:28 |
| kristianpaul | i think.. | 16:29 |
| wolfspraul | you can't expect to fool people multiple times | 16:29 |
| wolfspraul | maybe try a new name first :-) | 16:29 |
| wolfspraul | I think m1 is on good track and with the things we have learnt and are learning we will figure out how to sell it successfully | 16:30 |
| wolfspraul | I have no problem at all understanding the excitement behind rpi though | 16:30 |
| wolfspraul | m1 is pretty lousy on almost all tech specs I can think of | 16:30 |
| wolfspraul | compared to other 'modern' tech | 16:30 |
| lekernel | but the mirteo won't. | 16:30 |
| wolfspraul | so? the people we have found need to see other values | 16:30 |
| wpwrak | ah, 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#p43494 | 16:31 |
| wpwrak | it's "official", though | 16:31 |
| wolfspraul | I rather fix m1 bugs | 16:32 |
| kristianpaul | m1 either, still have dmx | 16:32 |
| kristianpaul | have you qoute a dmx controller recently? :) | 16:32 |
| wolfspraul | I don't believe the (many) shortcomings we have started to understand on m1 wouldn't reappear in later products again | 16:33 |
| wolfspraul | ah god, of course | 16:33 |
| wolfspraul | m1 is full of features that are started, full of bugs, never seriously fixed or marketed or tested or anything | 16:33 |
| wpwrak | lekernel: i think a monitor+touch combined with the existing M1 would be a much quicker way to a new user experience | 16:33 |
| Fallenou | +1 | 16:34 |
| Fallenou | step by step :) | 16:34 |
| wpwrak | the 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 screen | 16:34 |
| wpwrak | you can still aim for star trek aesthetics. they look good, even today :) | 16:35 |
| Fallenou | but the novelty effect could affect sells :) | 16:35 |
| Fallenou | there is little difference sometimes between a product that sells and a product that does not sell | 16:35 |
| wpwrak | Fallenou: yes, until VJs start complaining that they lost blocks and such | 16:35 |
| Fallenou | sometime it's just some design stuff | 16:35 |
| Fallenou | colour, texture | 16:35 |
| Fallenou | or just the brand =) | 16:35 |
| Fallenou | if you do a tablet, you get compared to Apple ipad etc | 16:36 |
| Fallenou | and you will never win | 16:36 |
| wpwrak | consider 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 |
| Fallenou | if you do a table with objects, you get compared to what ? :) | 16:36 |
| Fallenou | to nothing | 16:36 |
| wolfspraul | I 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 |
| Fallenou | you're just cool | 16:36 |
| wpwrak | each morning, they get to count now many they have lost. crawl on the floor, etc. | 16:36 |
| wpwrak | and every once in a while, the one they would need just now (during the show) can't be located. | 16:37 |
| Fallenou | indeed it's a problem | 16:37 |
| wpwrak | none of these issues happen if it's just a screen | 16:37 |
| Fallenou | you could think of a rf signal that makes them blink and play a loud sound | 16:37 |
| Fallenou | like some gadget not to lose your keys | 16:37 |
| wpwrak | plus, you can get industrially made rugged screens. | 16:37 |
| Fallenou | (rf signal, to please wolfspraul :D) | 16:37 |
| wpwrak | as if you would hear them beep for their mother while the music is on. you must visit very quiet clubs ;-) | 16:38 |
| Fallenou | ahah | 16:38 |
| Fallenou | search for them after the club is closed | 16:38 |
| Fallenou | while packing | 16:38 |
| Action: kristianpaul wonder how famous a reactable is now that the tables is on its rush | 16:38 | |
| wpwrak | and you've just made them quite a bit more expensive. now they need to store offline power, too. | 16:39 |
| lekernel | wpwrak: http://worrydream.com/ABriefRantOnTheFutureOfInteractionDesign/ | 16:39 |
| kristianpaul | whne i met the reactable 4 years ago was intersting, but now will call same atention? | 16:39 |
| Fallenou | indeed, it was just a random thought, maybe not a good idea :/ | 16:39 |
| kristianpaul | but 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 |
| wpwrak | but mirteo adds a lot more complications. things that most likely work against it. | 16:42 |
| kristianpaul | i agree with separate | 16:42 |
| lekernel | right now the only sensible argument against it is the lost objects | 16:42 |
| lekernel | any more? | 16:42 |
| wpwrak | and 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 |
| wpwrak | amount of work to get it to function reliably | 16:43 |
| wpwrak | also, you want to redo m1 in the process. this increases the amount of work even more. | 16:43 |
| lekernel | if we drop all the pesky stuff (USB, ...) it's not that much work | 16:43 |
| wpwrak | i don't think you believe that yourself ;-) | 16:43 |
| lekernel | I find the general M1 development could have been even more efficient | 16:44 |
| wpwrak | besides, as i mentioned, you don't have to worry about things like usb | 16:44 |
| wpwrak | the M1 would just be inside the frame | 16:44 |
| wpwrak | you can hide or reveal whatever you feel comfortable with at that time | 16:44 |
| wpwrak | and if you change your mind. that's just a matter of cutting a new frame. half a day of carpentry. | 16:45 |
| kristianpaul | lekernel: we do really need ddr3 and next xilinx chips _now_ to improve video out specs? | 16:46 |
| kristianpaul | lekernel: anymore, yes, start over again :) | 16:47 |
| wpwrak | we 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 functions | 16:47 |
| kristianpaul | good | 16:48 |
| kristianpaul | so the wall interface as an accesory to current m1 is what you propose right? | 16:48 |
| wpwrak | worst 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 |
| kristianpaul | lol | 16:49 |
| kristianpaul | :) | 16:49 |
| kristianpaul | and yes, | 16:53 |
| kristianpaul | wolfspraul still want a second screen? :) | 16:53 |
| kristianpaul | that idea/request came from long before i remenber | 16:53 |
| kristianpaul | now is the time it seems | 16:53 |
| wolfspraul | of course | 16:54 |
| wolfspraul | digital | 16:54 |
| wolfspraul | maybe with r4 we can drive both the vga & digital separately? | 16:54 |
| wolfspraul | but it depends on how much sebastien focuses on m1 at this point and gets the whole migen power to i1 | 16:54 |
| wolfspraul | otherwise we have to backport and that may be slow | 16:54 |
| wolfspraul | but we get to it, I think we have 2 screens on r4 | 16: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 system | 16:55 |
| lekernel | what about r5 with ddr3, -7 and dual video output? | 16:55 |
| wpwrak | but a 1 bpp channel for the secondary display should be no problem | 16:55 |
| wolfspraul | sure | 16:55 |
| wpwrak | lekernel: that would be a sensible evolution | 16:56 |
| lekernel | wpwrak: I think there might still be some bw left | 16:56 |
| wpwrak | even better :) | 16:56 |
| lekernel | but then there will be the compatibility problem with r5 | 16:56 |
| wolfspraul | r5 with -7 ddr3 etc would be great | 16:56 |
| kristianpaul | so, we do really need ddr3 and next xilinx chips _now_ to improve video out specs? | 16:56 |
| kristianpaul | lekernel: ^ | 16:56 |
| wpwrak | m1r4 could still do the same with 1 bpp :) | 16:57 |
| wolfspraul | compatibility will be a big issue, and at multiple layers of the system, but that's something we can help with I think | 16:57 |
| lekernel | wpwrak: but then software has to handle 1bpp | 16:57 |
| wpwrak | well, there's no free lunch :) | 16:57 |
| wolfspraul | kristianpaul: those things go in parallel | 16:57 |
| wolfspraul | m1rc3 is not maxed out | 16:57 |
| wolfspraul | m1r4 not even made yet | 16:57 |
| lekernel | kristianpaul: no. -ng should already increase the bandwidth by 2x to 4x | 16:57 |
| wolfspraul | and m1r5 only in conceptional stage | 16:57 |
| lekernel | on the current m1 boards | 16:57 |
| Fallenou | 2x 4x <= awesome :' | 16:57 |
| kristianpaul | wolfspraul: yes sure, i dont mind having a s-7 dd3 box _just_ for the full HD thing | 16:58 |
| wolfspraul | yeah | 16:58 |
| kristianpaul | Fallenou: indeed :) | 16:58 |
| wolfspraul | if 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 |
| wpwrak | the new gui will need quite a bit of work anyway. adding 1 bpp support should be a pretty minor item, compared to the rest | 16:58 |
| lekernel | wpwrak: I think the second fb could work at 16bpp | 16:59 |
| lekernel | maybe 32 even | 16:59 |
| wpwrak | that 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 |
| lekernel | we're using 3 gbps atm, switching to 32 would make that 6, and -ng has up to 10 | 17:00 |
| kristianpaul | wolfspraul: parallel indeed, but no drop one effort and begin other from scratch :) | 17:00 |
| wpwrak | sends a strong message of this being a tool that gets the job done | 17:00 |
| kristianpaul | bbl lunch | 17:00 |
| wolfspraul | enjoy | 17:00 |
| Fallenou | a framebuffer uses ram bandwidth quite efficiently, since it's always burst access | 17:01 |
| lekernel | -ng reorders ram transactions anyway to make them efficient most of the time :) | 17:01 |
| Fallenou | is there some case where reordering adds latency ? | 17:01 |
| lekernel | reordering always adds latency | 17:02 |
| lekernel | so 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 |
| lekernel | and TMU/FB/video-in will be redesigned to cope with latency better | 17:04 |
| Fallenou | ok | 17:05 |
| lekernel | there are some experiments to do, like disabling reordering for transactions that emanate from software and schedule them for minimum latency | 17:05 |
| lekernel | I can try that, if it turns out that some performance-critical software code becomes memory-bound | 17:06 |
| Fallenou | lekernel: http://pastebin.com/767KifbS why don't I see my uart_write() ? | 17:21 |
| Fallenou | it seem to hand the SoC | 17:21 |
| Fallenou | hang* | 17:22 |
| Fallenou | I guess it's blocked waiting for some ack/irq from uart core | 17:22 |
| Fallenou | but can't figure out why | 17:22 |
| Fallenou | am I not setting it up to polling mode ? | 17:22 |
| Fallenou | (just look at the main() ) | 17:23 |
| lekernel | hmm iirc there's no polling mode | 17:23 |
| lekernel | it always needs irqs | 17:23 |
| Fallenou | err my pastebin is wrong | 17:23 |
| Fallenou | it's not what I wanted to paste | 17:23 |
| lekernel | nevertheless I think I remember removing the polling uart code | 17:24 |
| Fallenou | here is the content of my main() : http://pastebin.com/rAd43s04 | 17:25 |
| Fallenou | oh | 17:25 |
| Fallenou | because now mmu activates itself upon interrupt/exception | 17:26 |
| Fallenou | but for debug purposes it was usefull to be able to do printf(); without activating mmu | 17:27 |
| lekernel | let me check... | 17:27 |
| Fallenou | to ensure that MMU does not activates itself when I don't want to, I disabled IRQ in the bios C code | 17:27 |
| Fallenou | but then indeed uart does not work anymore | 17:27 |
| Fallenou | ok thanks | 17:28 |
| lekernel | nah, print should still work | 17:28 |
| lekernel | https://github.com/milkymist/milkymist/blob/master/software/libbase/uart.c#L92 | 17:28 |
| lekernel | it's polling there | 17:28 |
| lekernel | does uart_force_sync() return? | 17:28 |
| Fallenou | ok that's what I thought | 17:28 |
| Fallenou | I could try to make a LED blink after uart_force_sync() to check | 17:29 |
| lekernel | I removed it in -ng but not in legacy | 17:29 |
| lekernel | (the polling) | 17:29 |
| lekernel | Fallenou: why not try printing something immediately before and after force_sync? | 17:29 |
| Fallenou | using uart_write() ? | 17:30 |
| lekernel | your uart doesn't work at all? even while the mmu is still disabled? | 17:30 |
| Fallenou | or directly writting to uart register ? | 17:30 |
| lekernel | uart_write | 17:30 |
| Fallenou | I think I tried and it did not write anything | 17:30 |
| Fallenou | let me recheck | 17:30 |
| Fallenou | it does not write anything | 17:31 |
| Fallenou | btw I am using regular bitstream, official milkymist one, without any MMU stuff | 17:32 |
| lekernel | is the uart cable correctly connected? | 17:33 |
| Fallenou | when I say "nothing", means nothing after SDRAM initialization text | 17:34 |
| Fallenou | All SDRAM initialization completed, boot continuing. | 17:35 |
| Fallenou | this is the last thing I can see | 17:35 |
| lekernel | even with milkymist.org/updates ? | 17:35 |
| Fallenou | what do you mean ? | 17:36 |
| lekernel | try the known-good images | 17:36 |
| Fallenou | the bitstream is the official one | 17:36 |
| Fallenou | the bios is modified | 17:36 |
| Fallenou | http://pastebin.com/u4c62y2q <= this is working (writting F in uart) | 17:38 |
| Fallenou | http://pastebin.com/q50HPnS0 <= this is not | 17:41 |
| lekernel | calling uart_init(); again will put you back into irq-driven mode | 17:44 |
| lekernel | you should call it only once | 17:44 |
| lekernel | at the beginning of main | 17:44 |
| lekernel | before force_sync or anything else | 17:44 |
| Fallenou | oh right ! | 17:44 |
| Fallenou | ok working now :) | 17:45 |
| Fallenou | thanks ! | 17:45 |
| Fallenou | I can see "EF" | 17:45 |
| Fallenou | I just moved uart_init() up | 17:45 |
| GitHub13 | [milkymist-ng] sbourdeauducq pushed 4 new commits to master: http://git.io/xjY4Gw | 17:49 |
| GitHub13 | [milkymist-ng/master] software/libbase: fix stupid mistake in limits.h - Sebastien Bourdeauducq | 17:49 |
| GitHub13 | [milkymist-ng/master] software/libbase: use compiler-rt - Sebastien Bourdeauducq | 17:49 |
| GitHub13 | [milkymist-ng/master] software/libbase: add strerror - Sebastien Bourdeauducq | 17:49 |
| Fallenou | test_user_abort() seems not to work in polling mode | 17:54 |
| Fallenou | it's using readchar_nonblock() | 17:54 |
| Fallenou | even if I enter ESC or Q it's booting from flash | 17:55 |
| Fallenou | I will just remove the test I guess | 17:56 |
| wpwrak | writing with polling still works ? that would be pretty essential for a lot of low-level work | 18:43 |
| lekernel | yes | 18:54 |
| lekernel | though not implemented in -ng, but that wouldn't be the hardest thing to do when needed | 18:54 |
| GitHub196 | [milkymist-ng] sbourdeauducq pushed 1 new commit to master: http://git.io/uUSx6w | 19:19 |
| GitHub196 | [milkymist-ng/master] software/libbase/vsnprintf: treat %g as %f (temporary hack) - Sebastien Bourdeauducq | 19:19 |
| GitHub52 | [misp] sbourdeauducq created master (+9 new commits): http://git.io/8vIyTg | 20:11 |
| GitHub52 | [misp/master] Initial commit. fdlibm. - Sebastien Bourdeauducq | 20:11 |
| GitHub52 | [misp/master] libm: rename fdlibm.h -> math.h - Sebastien Bourdeauducq | 20:11 |
| GitHub52 | [misp/master] gitignore - Sebastien Bourdeauducq | 20:11 |
| Fallenou | hum readchar without interrupt seems tricky | 22:00 |
| Fallenou | that 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 |
| Fallenou | gn8 ! | 22:12 |
| --- Tue May 29 2012 | 00:00 | |
Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!
