| dvdk | look here: www.iwar.org.uk/comsec/resources/cipher/sha256-384-512.pdf | 00:00 |
|---|---|---|
| dvdk | one block of sha256 takes 64 rounds (i.e. 64 cycles), and 8 registers a 32 bits. | 00:01 |
| kristianpaul | ah yes also crypto stuff :) | 00:01 |
| dvdk | for mining you need 2 blocks per hash, i.e. 128 rounds. so at 128 MHz you're at 1Mhash/sec, that's too low. | 00:01 |
| dvdk | so I guess people instantiate multiple hash-algos that work in parallel. | 00:02 |
| kristianpaul | ah, i havent check hash core lets hace a quick look | 00:02 |
| dvdk | so, try to scale the design down. | 00:02 |
| dvdk | i.e. reduce number of instantiated hashers. | 00:02 |
| dvdk | the spartan6 in mm1 is a pretty small model. | 00:02 |
| kristianpaul | yeah.. | 00:03 |
| kristianpaul | i tried lowering a LOOP_LOG2 paramer i found | 00:03 |
| kristianpaul | from some forums and the fpgaminer core | 00:03 |
| kristianpaul | this is derivated from ztex | 00:03 |
| Action: dvdk thinks people who run fpgaminer use *much* larger fpgas. | 00:03 | |
| kristianpaul | the cheat also | 00:04 |
| kristianpaul | use chipscore to read results i think | 00:04 |
| kristianpaul | s/the/they | 00:04 |
| kristianpaul | https://github.com/ngzhang/Icarus/tree/master/FPGA_project/Src is nice because implement serial comunciation | 00:05 |
| kristianpaul | dvdk: larger yes but there is people who oen atlys boards wich is quite similar to M1 | 00:06 |
| kristianpaul | s/oen/own | 00:07 |
| cladamw | wpwrak, do you think out a way that we can do design verification on DVI-I differential pairs on rc3 firstly? | 02:32 |
| wolfspraul | cladamw: good morning! :-) | 02:33 |
| cladamw | can rc3 be made it possible? | 02:33 |
| cladamw | wolfspraul, good morning . :) | 02:33 |
| cladamw | wpwrak, i knew it was bad that current wires from J21 came from bank1 not bank2 | 02:34 |
| cladamw | the TMDS signals do not supported in bank1 | 02:35 |
| wpwrak | oh, didn't know there were more constraints. when i asked if there were other "special" features besides the clock, nobody spoke up :-( | 02:37 |
| wpwrak | anyway, seems that we'll have to try our luck without dvi design testing | 02:38 |
| cladamw | hmm...i did also feel that way ! :( | 02:41 |
| cladamw | wpwrak, btw have you seen this thread already? http://lists.milkymist.org/pipermail/devel-milkymist.org/2011-October/001966.html | 02:42 |
| wpwrak | yes, i've seen it. do you expect any specific reaction from me ? i don't know much about dvi, so it's basically "aha, interesting" from me :) | 02:50 |
| cladamw | wpwrak, phew~ i see. I've be noticed myself that hopefully and to be carefully known well background knowledge behind dvi-i, there's 50 ohm in series on PMODA/JA for the "direct connection" example: http://www.digilentinc.com/Data/Products/ATLYS/Atlys_C2_sch.pdf | 03:13 |
| wpwrak | ah, you didn't have that yet. i see | 03:21 |
| cladamw | and compared to its HDMI OUT(J2) without need 50 ohm. The 50 ohm resistors which is designed for TMDS received to fpga after checked http://www.xilinx.com/support/documentation/user_guides/ug381.pdf | 03:22 |
| cladamw | the 50 ohm seems no need while act as receiver which differ to we act as a transmitter | 03:22 |
| wpwrak | maybe the termination for HDMI is already in the transceiver chip | 03:23 |
| cladamw | but from Atlys, i don't fully understand why there's a TI chip there. | 03:23 |
| cladamw | so my question is : would it as a must to pull fpga wire connection via buffer. | 03:24 |
| wpwrak | ug381 doesn't make sense :) | 03:25 |
| wpwrak | "The TMDS standard requires external 50 resistor pull-ups to 3.3V on inputs." | 03:25 |
| wpwrak | 50 Ohm **PULL-UP** ? yeah, sure ;-) | 03:26 |
| wpwrak | ah wait ... if they're combined with series resistors on output, that would make sense | 03:27 |
| wpwrak | okay, it does make sense :) | 03:27 |
| wpwrak | and then it's also logical that the outputs would have to have 50 Ohm series resistors | 03:28 |
| cladamw | yes, but which they are describing for tmds receiver not like our output goal, agreed? | 03:29 |
| wpwrak | hmm. figure 1-19 doesn't have output resistors | 03:30 |
| cladamw | correct | 03:30 |
| cladamw | also i strongle figured that we might misunderstand the distance vs skin effect, check my log: http://en.qi-hardware.com/mmlogs/milkymist_2011-12-08.log.html#t12:48 | 03:31 |
| wpwrak | so i don't know who is right. xilinx or digilent | 03:31 |
| wpwrak | maybe PMODA is something else that just looks like HDMI ? | 03:31 |
| wpwrak | the others say HDMI IN/OUT | 03:32 |
| cladamw | not sure, but we can't do 'direct connection' under things we don't really know. | 03:32 |
| cladamw | yes, | 03:32 |
| wpwrak | you can add 0Rs ;-) | 03:32 |
| cladamw | but ours is much close to act as a like HDMI OUT, correct? | 03:33 |
| cladamw | so my question is still : why add buffer? | 03:33 |
| wpwrak | their HDMI out has a special chip. so that doesn't tell us anything. | 03:33 |
| cladamw | did we miss important specifications behind TMDS ? | 03:33 |
| wpwrak | maybe protection. maybe it produces a cleaner/stronger/etc. signal ? | 03:33 |
| cladamw | so please read : page 2 from http://www.pericom.com/pdf/applications/AN204.pdf | 03:34 |
| wolfspraul | cladamw: we don't need the TI buffer chip | 03:35 |
| wolfspraul | that was discussed several times already | 03:35 |
| cladamw | wolfspraul, wait | 03:35 |
| cladamw | i am confirming and discussing with Werner about high frequency behavious to know why. | 03:35 |
| wpwrak | (270-280 mil) yeah, seems a little weird :) | 03:36 |
| cladamw | wpwrak, from that pericom data which is MUCH Importatce that we need buffer ! | 03:36 |
| cladamw | so i double checked http://en.qi-hardware.com/mmlogs/milkymist_2011-12-08.log.html#t10:09 | 03:37 |
| cladamw | when I reviewed that. | 03:37 |
| cladamw | so we need very sure that (270-280 mil) which already against our current planned distance from fpga to dvi conector | 03:38 |
| cladamw | so I need to SPEAK up this in advance, at least we really fully understand the content of pericom and schematic example from ATLYS. | 03:40 |
| wpwrak | i couldn't make sense of these design parameters back then and i can't now :-( | 03:42 |
| wpwrak | pericom specify nearly impossible requirements | 03:42 |
| wolfspraul | we don't need the buffer chip | 03:42 |
| wolfspraul | it was discussed 5+ times | 03:42 |
| wpwrak | existing boards place things at large distances apparently without problems | 03:42 |
| wolfspraul | yep | 03:42 |
| wpwrak | so there's something that doesn't add up | 03:43 |
| wolfspraul | everybody tries to sell their stuff | 03:43 |
| wolfspraul | what's better than selling into fear :-) | 03:43 |
| wpwrak | maybe pericom are specifying for excessive data rates or such | 03:43 |
| wpwrak | ;-) | 03:43 |
| cladamw | wpwrak, no problem, take you r time. i just feel pericom has that important data to know what idea behind it, and would it be related to why there's buffer added in ATLYS? | 03:43 |
| wolfspraul | there's a buffer on atlys because TI paid them to add it | 03:43 |
| wolfspraul | and it seems to work :-) | 03:43 |
| wolfspraul | now you think you need it too :-) | 03:43 |
| wpwrak | cladamw: it's not a question of time but of dvi design experience :) | 03:44 |
| wolfspraul | seriously the buffer on the atlys board is really there because TI paid | 03:44 |
| wolfspraul | in fact there are 2 outputs on that board, one with the buffer and one without | 03:45 |
| wolfspraul | seems atlys didn't want to let TI take hostage of their customers entirely... :-) | 03:45 |
| wolfspraul | if we need the buffer chip, we have to find out from hard requirements, not from fear | 03:45 |
| wpwrak | dimissing buffers just a FUD seems a bit too simple :) | 03:45 |
| wolfspraul | and for the time being we are aware of existing boards that indicate that we do not need the chip | 03:46 |
| wolfspraul | I don't | 03:46 |
| wpwrak | frequency ranges would be something i could accept as an explanation | 03:46 |
| wpwrak | or cable length | 03:46 |
| cladamw | wpwrak, i am more focusing on pericom theory on its analysis. not saying if we must add buffer or not. | 03:46 |
| wolfspraul | but we had this discussion 5 times | 03:46 |
| wolfspraul | resolution and bandwidth can go very high | 03:46 |
| wolfspraul | it's not binary | 03:46 |
| wolfspraul | it's not like you always need the chip, or never | 03:46 |
| wolfspraul | but most likely on m1 r4, the buffer chip would serve no purpose | 03:46 |
| wolfspraul | but you can clearly see the power of devel boards here, and that it makes sense to have your chips on them :-) | 03:47 |
| cladamw | atlys added buffer is for htmi extendable cable | 03:47 |
| wolfspraul | it's because TI paid | 03:47 |
| cladamw | but for ourside, surely the dvi-i extendable cable is still be used for m1. | 03:48 |
| wolfspraul | I believe that (in)famous atlys board has a second hdmi without buffer chip. that's fair enough, so the (developer) users of that board can compare the actual performance and need of the TI buffer chip. | 03:49 |
| wolfspraul | I am quite certain that we don't need the buffer chip on m1 r4, or rather that it would not serve any meaningful purpose. | 03:49 |
| wolfspraul | after this having been discussed several times | 03:49 |
| wpwrak | what's the maximum length of a DVI cable anyway ? maybe that's the thing. monitor right next to the computer vs. projector at the other side of the room | 03:50 |
| wolfspraul | I think stekern pointed to some boards that are happy without it, up to resolutions that are so high that I would jump up and down in joy if m1 can get there... | 03:50 |
| cladamw | if TI buffer is designed for buffering TMDS signals, why in our side, as we still need dvi cable connected to dvi monitor, would it be still act well with long cable? | 03:50 |
| wolfspraul | wpwrak: but you bet there are cables with built-in buffers/signal improvement ics or whatever as well | 03:50 |
| wolfspraul | cladamw: we have to find out | 03:50 |
| wolfspraul | but we start without the TI chip | 03:51 |
| wpwrak | wolfspraul: $$$ cables :) | 03:51 |
| wolfspraul | yes but we cannot just add chips because we know nothing | 03:51 |
| cladamw | so please let us be carefullu on this. | 03:51 |
| wolfspraul | but we can make the first step, even if we know nothing | 03:51 |
| wolfspraul | cladamw: the chip is not needed | 03:51 |
| wolfspraul | it was discussed many times | 03:51 |
| wpwrak | so, m1r4 probably only with short dvi cables, m1r5 with unlimited ones ;-) | 03:51 |
| wolfspraul | maybe | 03:52 |
| cladamw | if dvi cable bounded with buffer inside, then safe, but which is not common i think. | 03:52 |
| wolfspraul | sure sure | 03:52 |
| wolfspraul | you guys can discuss | 03:52 |
| wolfspraul | :-) | 03:52 |
| wpwrak | if you need an active cable for anything, that means you're desperate. prices are according ;-) | 03:52 |
| wolfspraul | the chip is not needed | 03:52 |
| wolfspraul | there's a link somewhere to a board or boards and the resolutions achieved without buffer | 03:53 |
| wolfspraul | which doesn't mean we will see the same performance on m1 r4 of course | 03:53 |
| cladamw | board to board without buffer I can agreed, but now our case is board to long dvi cable. | 03:54 |
| wolfspraul | we don't need the buffer | 03:54 |
| wolfspraul | but I do suggest that we make the first run of r4 only 6-10 pc or so | 03:55 |
| wolfspraul | accelerate that | 03:55 |
| wolfspraul | http://rubidium.dyndns.org/pipermail/fpga-synth/2011-April/001667.html | 03:57 |
| wolfspraul | let me paste a little from that nice mail... :-) | 03:57 |
| wolfspraul | since you torture me, I torture back | 03:57 |
| wolfspraul | "Contrary to what I thougt it appears that | 03:57 |
| wolfspraul | the HDMI buffer chip doesn't play a role in getting the "too fast" signals | 03:57 |
| wolfspraul | out. | 03:57 |
| wolfspraul | The 193MHz pixel clock was actually producing a bit cleaner picture | 03:58 |
| wolfspraul | with the direct output (to be fair, that exceeds the spec of the HDMI buffer | 03:58 |
| wolfspraul | chip by quite some margin). | 03:58 |
| wolfspraul | --- | 03:58 |
| wolfspraul | does this apply to m1 r4? I don't know | 03:58 |
| wolfspraul | but I feel quite confident that we should do m1 r4 without the buffer chip, and apply everything else to the best of our knowledge in terms of the wires, signal integrity, etc. | 03:59 |
| wpwrak | yeah, considering that this isn't the only unknown about dvi, probably a reasonable choice | 04:02 |
| wolfspraul | cladamw: we were told from people that designed/made hdmi boards before that we should not need the TI buffer chip | 04:05 |
| wolfspraul | I think that's enough | 04:05 |
| wolfspraul | so let's focus on everything else ;-) | 04:05 |
| wolfspraul | we may still discover the value/need of that chip later, but the best way to that discovery is to first try without it | 04:05 |
| wolfspraul | otherwise I don't see what next step you propose :-) | 04:05 |
| cladamw | wolfspraul, well fine that link, if you think 'one' link can prove unconcerned tasks, i just didn't want dvi-i connector with failure in the end then go R5. | 04:11 |
| wolfspraul | I carefully thought about this [buffer chip] | 04:11 |
| wolfspraul | I think about the different paths | 04:12 |
| wolfspraul | which actual path do you propose? | 04:12 |
| wolfspraul | I am not saying I know what will work | 04:12 |
| wolfspraul | but i am pretty sure that we should first make R4 without buffer chip | 04:12 |
| wolfspraul | and do everything else as best as we can on signal integrity | 04:12 |
| wolfspraul | even there we have some exceptions because we don't want to move existing pins, or even rotate the entire s-6 | 04:12 |
| wolfspraul | those are all options we theoretically have, but choose not to do because we "think" they are not needed | 04:13 |
| wolfspraul | I do propose that the first SMT run of R4 be only 6-10 pieces though | 04:13 |
| wolfspraul | among other things because of DVI signal integrity | 04:13 |
| wolfspraul | that should make you feel better, no? :-) | 04:13 |
| cladamw | i do have no actually path i can do now, just liked i also got 'one' link of data, then i spoke up. | 04:13 |
| wolfspraul | oh yes | 04:13 |
| wolfspraul | that is very good! | 04:13 |
| wolfspraul | we may be desperately looking for that link in a few weeks :-) | 04:14 |
| wpwrak | it may make sense to consider the possibility of adding such a buffer chip in the future when doing the layout. i.e., to make sure the DVI area isn't overly crowded | 04:14 |
| cladamw | so what current channel we have now in here, i just wanted to rise up this again surely i don't have alternative solutions. | 04:15 |
| wolfspraul | wpwrak: such a requirements would only confuse layout | 04:16 |
| wolfspraul | if such a chip is to be added, it's a layout change anyway, and can be looked at then | 04:17 |
| wolfspraul | the goal now is to make no signal integrity mistakes in R4 | 04:17 |
| wolfspraul | not to prepare for R5 | 04:17 |
| wolfspraul | if anything I think the issue of 'no reordering of existing pins' or 'rotate s-6' or 'move dvi-i connector to other side' could make more sense to think about | 04:18 |
| wolfspraul | should we move the dvi-i connector to another side? | 04:18 |
| wolfspraul | that'd be a massive layout change... | 04:18 |
| wpwrak | (rotate the fpga) yes, if it comes to that, it gets messy | 04:18 |
| wolfspraul | but the side panels of the case change anyway, from the mechanical side it's manageable | 04:19 |
| wolfspraul | I am not proposing that btw | 04:19 |
| wolfspraul | but if the "buffer chip" discussion comes up, there is no reason to not also discuss rotating the s-6 or moving the dvi connector to another side... | 04:19 |
| wolfspraul | how do we know that that wouldn't help more? -> we don't | 04:19 |
| wolfspraul | so I think best path is shortest path to actual (small) R4 run | 04:20 |
| wpwrak | (move dvi elsewhere) hmm, sounds messy | 04:20 |
| wolfspraul | make only small modifications if possible | 04:20 |
| wpwrak | you'd have to swap with midi and/or dmx | 04:20 |
| wpwrak | one issue is that the balls will be about 7 cm from the connector. that's ten pericoms (the pericom being a unit of paranoid distance) | 04:21 |
| cladamw | i was not to convince or torture, since as engineering thoughts, just don't want it being failed in R4 in the end. Compromising in determined by route or rotating s-6 decision is not most topic we want now. I just don't have more confidence when i digged-into seeing pericom & atlys info, i suddently have no confidence at all. | 04:22 |
| wolfspraul | I think we should not do that | 04:22 |
| wolfspraul | but as I said a few times now, I do think the first R4 smt run should only make 6-10 pieces | 04:22 |
| cladamw | wpwrak, yes, ten times | 04:22 |
| wolfspraul | we understand the industry currently works on quad-HD and stuff... | 04:22 |
| cladamw | so I want more people like wpwrak can spend some times to dig-into...i am enbarrassing though. :( | 04:23 |
| wolfspraul | we do that after we have made some R4 boards | 04:23 |
| wolfspraul | (without buffer chip) | 04:23 |
| wolfspraul | that's the most economical way | 04:24 |
| cladamw | wolfspraul, okay | 04:24 |
| wolfspraul | cladamw: did you see what i wrote about size of initial r4 smt run? | 04:24 |
| wolfspraul | we are making a lot of (good) changes | 04:25 |
| wolfspraul | and I also want to accelerate those changes, not get stuck worrying forever | 04:25 |
| wolfspraul | but then in return, I think we should only make a few boards first | 04:25 |
| wolfspraul | 6 or 8 or so | 04:25 |
| cladamw | now you 6 - 10 | 04:25 |
| wolfspraul | if they are fine, they can be built into full products | 04:25 |
| wolfspraul | we can make more PCBs right away, but a smaller SMT first | 04:25 |
| wolfspraul | it's just an idea how to accelerate | 04:26 |
| wolfspraul | and take some stress from you :-) | 04:26 |
| wolfspraul | if those 6-10 boards don't work, it's all on me :-) | 04:26 |
| wolfspraul | (or some part of them doesn't work...) | 04:26 |
| wolfspraul | cladamw: if we are lucky, the layout people have routed digital video before? maybe they have some feedback as well? | 04:27 |
| cladamw | wolfspraul, sure, need to get feedback from them, but not now. since we've not finished all else details, so i don't want to bother them now. | 04:29 |
| wolfspraul | sure | 04:29 |
| wolfspraul | have to run, bbl | 04:32 |
| GitHub92 | [migen] sbourdeauducq pushed 1 new commit to master: https://github.com/milkymist/migen/commit/1a86f26a66a357dce548a279b22badf6ab2d0443 | 10:24 |
| GitHub92 | [migen/master] bank/csrgen: use enumerate - Sebastien Bourdeauducq | 10:24 |
| cladamw | (2 pins header) wpwrak J25's two +5V pins connects to a 2x1 header without jumper in default: http://downloads.qi-hardware.com/people/adam/m1/tmp/m1r4/FPGA_J25_header_20120206.pdf | 12:33 |
| cladamw | do you meant like in this way? did i misunderstand? | 12:33 |
| cladamw | I drew J25 besides J21. | 12:34 |
| GitHub90 | [migen] sbourdeauducq pushed 1 new commit to master: https://github.com/milkymist/migen/commit/f3ddfffc470b0a59e9d02b7b9bc63f7f3da5e9ba | 13:01 |
| GitHub90 | [migen/master] bank: refactoring - Sebastien Bourdeauducq | 13:01 |
| GitHub146 | [migen] sbourdeauducq pushed 1 new commit to master: https://github.com/milkymist/migen/commit/3a2a0c4dd80c40cd34b783113c058f5047e6e793 | 15:21 |
| GitHub146 | [migen/master] bank: support registers larger than the bus word width - Sebastien Bourdeauducq | 15:21 |
| GitHub37 | [migen] sbourdeauducq pushed 1 new commit to master: https://github.com/milkymist/migen/commit/fcd6583cbbcc366c16e9bc1038dc305aaf323c75 | 16:45 |
| GitHub37 | [migen/master] bank: event manager - Sebastien Bourdeauducq | 16:45 |
| GitHub11 | [milkymist-ng] sbourdeauducq pushed 2 new commits to master: http://git.io/1EZL1Q | 16:51 |
| GitHub11 | [milkymist-ng/master] UART: use new bank API and event manager - Sebastien Bourdeauducq | 16:51 |
| GitHub11 | [milkymist-ng/master] top: connect UART IRQ - Sebastien Bourdeauducq | 16:51 |
| GitHub187 | [milkymist-ng] sbourdeauducq pushed 1 new commit to master: http://git.io/kZ1p1Q | 16:59 |
| GitHub187 | [milkymist-ng/master] software: use new UART - Sebastien Bourdeauducq | 16:59 |
| GitHub129 | [migen] sbourdeauducq pushed 1 new commit to master: https://github.com/milkymist/migen/commit/1eb348c573dfb68c67ed09445e5fdb5f524ac8b6 | 17:12 |
| GitHub129 | [migen/master] fhdl: do not attempt slicing non-array signals to keep Verilog happy - Sebastien Bourdeauducq | 17:12 |
| lekernel | $ cat lenovo_laptops_are_shit.sh | 17:13 |
| lekernel | #!/bin/sh | 17:13 |
| lekernel | while true; do | 17:13 |
| lekernel | killall -STOP par | 17:13 |
| lekernel | killall -STOP map | 17:13 |
| lekernel | sleep 1 | 17:13 |
| lekernel | killall -CONT par | 17:13 |
| lekernel | killall -CONT map | 17:13 |
| lekernel | sleep 1 | 17:13 |
| lekernel | done | 17:13 |
| lekernel | an alternative is to put that piece of crappy hardware outside where it's -16C ... | 17:14 |
| larsc | i7? | 17:16 |
| lekernel | core2 duo T9300 | 17:17 |
| lekernel | with an obviously lousy cooling system | 17:17 |
| wpwrak | ;-)) | 17:25 |
| GitHub97 | [migen] sbourdeauducq pushed 1 new commit to master: https://github.com/milkymist/migen/commit/47883675dbf71dc98814930330e7e2b68b56c808 | 17:49 |
| GitHub97 | [migen/master] bus/wishbone2csr: truncate WB data - Sebastien Bourdeauducq | 17:49 |
| lekernel | Fallenou: did you fix the RAM problems? | 18:07 |
| Fallenou | icache and dcache are now working fine | 18:14 |
| Fallenou | icache pb was solved by your commit about WE | 18:14 |
| Fallenou | dcache solved by initializing register 0 in lm32_dp_ram.v | 18:15 |
| Fallenou | funny thing is that clogb2(4096) == 13 for isim | 18:16 |
| Fallenou | i'm using clogb2_v1 now | 18:17 |
| Fallenou | i wonder if this bug screws up anything else | 18:18 |
| lekernel | I have problems with < 32-bit accesses atm | 18:24 |
| lekernel | in sram | 18:24 |
| lekernel | probably a typo somewhere ... | 18:24 |
| Fallenou | i didn't check all the values btw | 18:25 |
| Fallenou | just that the pattern i see in the wave form is correct | 18:25 |
| Fallenou | but i have not seen unexplainable values | 18:25 |
| Fallenou | i just have a loop with a few lb | 18:25 |
| Fallenou | and nops | 18:25 |
| Fallenou | atm | 18:25 |
| lekernel | reading bytes works, it's only with writing bytes or 16-bit words that there are problems | 18:28 |
| Fallenou | oh ok | 18:29 |
| Fallenou | thats why I didn't see it | 18:30 |
| Fallenou | omg your script | 18:48 |
| Action: Fallenou is not in such a bad position with his mac book pro virtualizing a debian | 18:48 | |
| Fallenou | now I understand why they put clogb2()-1 everywhere | 18:50 |
| Fallenou | because their log2 is log2 + 1 | 18:50 |
| Fallenou | crazy | 18:50 |
| sionneau | damn, freenode server maintenance | 20:26 |
| dvdk | huh, found an error in the gcc toolchain's disassembler? or do i just need more coffee: | 21:24 |
| dvdk | printf '\x4f\x00\xff\xff' > /tmp/opcode && /opt/rtems-4.11/bin/lm32-rtems4.11-objdump -EB -b binary -m lm32 -D /tmp/opcode | 21:25 |
| dvdk | this prints 0:4f 00 ff ff bge r24,r0,0xfffffffc | 21:25 |
| dvdk | but according to the LatticeMico32 Reference Manual, it should quite clearly be (bge r0,r24,...) | 21:25 |
| dvdk | i.e. order of registers is displayed wrongly | 21:25 |
| dvdk | ok, echo 'bge r24,r0,-4' > /tmp/test.asm, assembling, then disassembling gives identity. | 21:29 |
| dvdk | so i guess the manual is wrong!? | 21:29 |
| Fallenou | lekernel: http://sionneau.net/mmu/ :-) | 21:46 |
| Fallenou | this sets up a DTLB entry to map 0x1000 to 0x0000 and then reads from 0x1000 | 21:47 |
| Fallenou | oops this proves nothing | 21:48 |
| Action: Fallenou shouting victory too soone | 21:48 | |
| Fallenou | soon* | 21:48 |
| kristianpaul | good :) | 21:49 |
| Action: Fallenou needs to enlarge sram of the project | 21:50 | |
| Action: Fallenou needs several pages | 21:50 | |
| lekernel | and wait until you get mmu schrödinbugs in the middle of linux kernel tests :-) | 21:56 |
| Fallenou | lekernel: why is sram0_wishbone_adr_i 10 bits wide ? | 21:56 |
| larsc | lekernel: you can still blame linux for it | 21:57 |
| Fallenou | ahah yep schrodinbugs ==) | 21:57 |
| Fallenou | ok nevermind it's normal | 21:57 |
| Fallenou | I was reading 4096 in megabytes ... it's in kilobytes | 21:58 |
| dvdk | cool, you already have a (working?) mmu for LM32? | 22:09 |
| Fallenou | I thought it was starting to work | 22:19 |
| Fallenou | but no, not yet :) | 22:19 |
| Fallenou | but I'm quite done putting lm32 simulation in place, finish debugging the debug environment :) | 22:19 |
| Fallenou | now I can start working on debugging the mmu | 22:19 |
| dvdk | milkymist moves forward at a pace that I can hardly follow :) | 22:20 |
| Fallenou | yes, there is a bunch of very productive people over here :) | 22:21 |
| Fallenou | it's quite amazing | 22:21 |
| dvdk | wrt debugging the debug environment, I'm currently trying to port gforth-ec over to LM32 to use as a debug "operating system". Don't like to cross-compile&upload a hundred times just for testing a SoC components | 22:24 |
| Action: kristianpaul dont like cross-compile either | 22:26 | |
| lekernel | uploading is pretty fast with netboot and a script | 22:27 |
| dvdk | lekernel: yeah, but then it looses state, whenever I upload :) | 22:28 |
| Fallenou | gn8 ! | 22:29 |
| kristianpaul | n8 | 22:29 |
| dvdk | btw looking at the bios sources it seems like it will load from flash first, before reverting to netboot? need to write sth to flash to force netboot? | 22:29 |
| kristianpaul | and set up netboot enviroment :) | 22:29 |
| lekernel | you can press F8 during boot, and it will netboot | 22:30 |
| lekernel | alternatively you can erase FN from your flash so you don't have to press F8 every time (it'll only boot from network) | 22:30 |
| dvdk | lekernel: ah cool, F8 is easy to remember. | 22:31 |
| GitHub145 | [milkymist-ng] sbourdeauducq pushed 1 new commit to master: http://git.io/UGrWvQ | 22:45 |
| GitHub145 | [milkymist-ng/master] sram: fix sub-word write - Sebastien Bourdeauducq | 22:45 |
| Action: lekernel found a ACPI hack to double the speed of the fan. now it's noisy, but at least fpga compilations can run. | 23:11 | |
| wpwrak | what will you do in summer ? move south ? | 23:22 |
| GitHub110 | [milkymist-ng] sbourdeauducq pushed 1 new commit to master: http://git.io/DcnAVw | 23:42 |
| GitHub110 | [milkymist-ng/master] software: interrupt driven UART working - Sebastien Bourdeauducq | 23:42 |
| GitHub168 | [milkymist-ng] sbourdeauducq pushed 2 new commits to master: http://git.io/3g70mg | 23:51 |
| GitHub168 | [milkymist-ng/master] LM32: make IP read-only and interrupt lines level-sensitive - Sebastien Bourdeauducq | 23:51 |
| GitHub168 | [milkymist-ng/master] software: remove unnecessary IRQ acks - Sebastien Bourdeauducq | 23:51 |
| --- Tue Feb 7 2012 | 00:00 | |
Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!