IRC logs for #openrisc Saturday, 2014-05-10

--- Log opened Sat May 10 00:00:42 2014
stekern_franck_: can you test with what's in my branch?05:21
stekernpgavin: (l.sf heh, that kinda defeat the purpose of moving it then ;)05:22
stekernbut nice to hear you've got some progress on that05:23
blueCmdstekern: I want to discuss how to do 1, 2 and possibly 8 byte operations06:48
blueCmdI'm thinking of doing l.lwa rD, rA & ~3 and then shift and mask rD depending on rA & 306:49
blueCmd(or rather, doing this into a new rS or something, since rD is needed for the l.swa)06:50
blueCmdthen compare rS with old, if set shift 0xff 'to' rA & 3, negate it, AND it with rD, shift 'new' with rA & 3 and OR it with rD06:54
blueCmdand set mem = rD06:54
blueCmdbut it's a lot of insns06:54
_franck_stekern: it doesn't work with your branch neither. I did not update my gcc.06:58
stekern_franck_: umm... very strange then, that I *know* worked with the old or32-elf-gcc and ethoc06:59
stekernblueCmd: I think I would understand better if you'd just spelled the instructions out ;)07:07
blueCmdstekern: I'm doing that atm07:07
pgavinstekern: I think I've fixed that problem07:10
pgavinit's looking pretty good07:10
pgavinis there a cycle-accurate simulator for the mor1kx?07:11
pgavinother than the verilog i mean :)07:11
stekernwhat's wrong with the verilog? )07:15
stekerni.e., the answer is no, the best/fastest cycle-accurate simulator we have is verilated verilog07:18
blueCmdstekern: I'm going to move stuff around to make the distance between lwa and swa as small as possible07:18
blueCmdwhen implementing it07:18
blueCmdtime to shower, brb07:19
pgavinstekern: nothing's wrong with it :)07:24
pgavinsoftware simulators are just faster and sometimes have more flexibility07:25
pgavinso I was just wondering07:25
stekernyeah, there is or1ksim of course that goes more into the simulator genre, but it's not anywhere near cycle-accurate07:27
pgavinare there scripts etc. for building the simulator?07:28
stekernwith verilator you mean?07:29
pgavinor icarus is ok too I suppose07:29
blueCmdstekern: l.sfeq rC, old ofc - not rD07:29
pgavinverilator *.v ? :)07:29
stekernfusesoc/orpsoc-cores and then the mor1kx-generic system07:30
stekernwait, I have an old Makefile recipe for setting stuff up07:30
stekernit was for my eco32 system, but should be easy to modify it for 'mainline' and mor1kx-generic07:31
stekernmake checkout && make fusesoc && make mor1kx-generic07:36
stekernshould be all you need07:36
stekernit expects two files in the same directory07:37
stekernfusesoc.conf that contains this:
stekerndunno why I didn't make the Makefile generate that...07:38
stekernand vmlinux07:38
blueCmdstekern: second iteration, - have a look when you have time, no hurry07:39
pgavinstekern: thanks :)07:39
blueCmdi'm thinking of making that an 'cmpxchg_mask' of the second part and reusing it for 1 and 2 byte operations07:41
stekernpgavin: ah, sorry  you'll of course need - make verilator && make verilator-install too07:41
stekernbut I have no doubt that you'll be able to figure stuff out on your own from that crude Makefile ;)07:42
pgavinyeah, it's pretty straighforward :)07:42
pgavinhow long does it take to boot linux in the simulator?07:43
stekernblueCmd: maybe we should have speced the l.lwa to not generate align exceptions...07:43
stekernpgavin: in verilator - around 10-20 min, in icarus - 24h+07:44
pgavindidn't realize icarus was that slow07:44
pgavinbut I haven't used it for much07:44
stekernverilator is really fast enough to be useful07:44
stekernI get around 0.5MHz from it07:45
pgavinone core of the OpenSPARC T1 simulated at ~1kHz with Synopsys VCS07:46
pgavinI was amused by that07:47
pgavinbut that was dumping lots of trace data IIRC07:47
stekernyes, if you turn on trace dumping or vcd generation, it's of course a lot slower07:48
stekernbut usually you know around where you want the trace/vcd dumped, so you can just run it without those turned on up until that point07:48
blueCmdstekern: I don't know, it's not that much more of a hassle to mask the addr, right?07:49
pgavinstekern: basically I just want to benchmark some code to make sure my changes to the optimizer are effective07:51
pgavinso I shouldn't need any tracing, just some stats07:52
-!- Netsplit *.net <-> *.split quits: hno`08:18
-!- Netsplit over, joins: hno`08:29
pgavinhm...  is there a way to make fusesoc *not* check out the sources again?08:31
pgavinlike, if I make changes?08:31
pgavinor is there a better way to do it?08:31
-!- Netsplit *.net <-> *.split quits: hno`09:25
-!- Netsplit over, joins: hno`09:36
FindetonI have openrisc linux sim compiled and installed from scratch, including newlib and uclibc tools10:01
Findetonnow I want to compile a simple helloworld C++ program and run it on linux10:01
Findetonso I compiled it using or1k-elf-g++ helloworld helloworld.cpp10:02
pgavinthat won't work10:02
Findetonand then I included it in the initramfs10:02
Findetonit doesn't work, you are right pgavin10:02
pgavinor1k-elf-g++ is for running on bare metal10:02
pgavinuse or1k-linux-g++ if you want to run in linux10:03
Findetonahhh ok thanks!10:03
pgavinnp :)10:03
Findetonalthough it will also be fun to run a helloworld on bare metal too10:03
pgavinsure, and that's easy10:03
pgavinjust compile and do or1k-elf-sim $file10:03
pgavinyou'll need the config file of course10:04
Findetonso it's not that easy then, I need to do a config file :p10:04
FindetonI'll do it later10:04
FindetonI need to learn to do it sooner or later anyway10:05
Findetonbtw in my system it's or1k-linux-uclibc-g++, quite long!10:06
pgavinthere's a usable config in the or1ksim tarball10:07
Findetonuhm, can I just use the same config file I use when I boot linux?10:08
pgavinshould work find10:08
Findetonthat's good!10:09
Findetonalso, it's a curious thing that I need to rebuild the kernel when I change the contents of initramfs, isnt there an easiest way?10:13
FindetonI mean, in the future I'll get an ext2 system configured and all the like but..10:13
pgavinyeah, I haven't done a lot with that10:15
pgavinI'm sure someone else will be around that will know10:15
Findeton# ls10:17
Findeton# ./has10:17
Findeton-sh: ./has: not found10:17
Findetonhas is the helloworld app built with uclibc, what the hell is happening?10:17
Findeton(i'm executing that in the openrisc linux through a telnet session)10:18
pgavinis the file in the initramfs?10:24
Findetonyes it is10:24
pgavinis it staticly linked?10:25
Findetonand I have tried and at least the bare metal version works10:25
pgavinthe initramfs might not have the stuff for dynamic linking10:25
pgavinthat not found might be referring to ld.so10:25
Findetonuhm, and how can I do the static linking while compiling?10:25
pgavinon the link line10:25
Findetonwell I did it all in just one line10:26
pgavinok, just add it to the one line10:26
Findetonok lets do this!10:26
Findetonbut it is strange that it works in the metal version10:28
pgavinyou mean the has executable runs straight off or1ksim?10:28
pgavinthat means you didn't use the right compiler10:28
pgavinyou need to compile the executable using or1k-linux-gcc, then put it in your initramfs10:29
Findetonno, the has is the clibc version :)10:30
pgavinthen it shouldn't run directly in the simulator i don't think10:31
Findetonnow it works!10:31
Findetonpgavin: I compiled two versions, 'mas' is the baremetal and 'has' the linux version10:32
Findetonthanks for the help btw!10:32
pgavinsure, np :)10:33
Findetonnow that I think about it I'll only need the bare metal thing but it's good to know how to compile it for linux!10:35
Findetonoh no, I must need both10:35
pgavinyou should be able to compile the kernel with the linux toolchain now10:43
pgavinI'm pretty sure stefan fixed that anyways10:44
-!- Netsplit *.net <-> *.split quits: hno`10:54
stekernpgavin: fusesoc will cache the  cores in .cache11:00
stekerni.e. it will only download them oncd11:01
pgavinso what if I want to make modifications?11:02
pgavinshould I do them there?11:03
stekernnow, the caching functionality could need some improvements. but thats high on the todo lust, right olofk ;)11:04
pgavinlooks like it doesn't keep the .git stuff11:04
stekernyes, you can do them there. you can also prevent fusesoc from downloading and using a local version in the orpsoc-cores dir11:05
pgavinso I modify the corresponding file in orpsoc-cores to point to a local directory?11:05
-!- Netsplit over, joins: hno`11:06
stekernI usually do quick and dirty small in .cache and the latter for bigger stuff11:06
pgavinworks for me :)11:06
stekernif you rwmove the provider entey it'll look in the dir the .core file is11:07
pgavinI only needed a small modification11:07
pgavinthe testbench doesn't detect NOP_EXIT_SILENT11:07
pgavinjust NOP_EXIT11:07
stekernah, but tb.cpp is "local" anywat11:08
* stekern writes with phone11:09
pgavinah, that's already in oprsoc-cores11:10
pgavinthat makes it easy11:10
pgavinI was confused, I thought fusesoc was also pulling the testbench tree from somewhere :)11:14
stekernif you need the actual exit code, fusesoc will not return it as things currently stands11:32
stekernI noticed that the other day11:33
stekernyou can however get it by running the simulator directly with the Vorpsoc_top exe after fusesoc built it for you11:34
pgavinI didnt realize I need gdb11:57
pgavinI guess I start the sim, then connect with gdb?11:57
stekernah, you can do that, but you don't need to(?)11:58
pgavintrying to figure out what's going on them11:59
stekernyou can load elfs with --elf-load=<file>11:59
pgavinyeah, I did that11:59
pgavinand it just hung11:59
pgavinbut there might by a problem with the binary11:59
stekernok, that's not how it's intended to work ;)12:00
pgavinwell I ran it with --elf-load12:01
pgavinnothing happened12:01
pgavinI hit ctrl-c12:01
pgavinit says stopped at PC 0000000012:01
pgavinoh, and the vcd was empty for some reason12:02
stekernhmm, that sound strange12:03
stekerndid you run it with --vcd?12:03
pgavinpython fusesoc sim --sim=verilator mor1kx-generic --elf-load test -vtest.vcd12:04
stekernok, I was just thinking if it creates an empty vcd when the --vcd commandline option isn't there12:05
pgavinthe binary runs fine with or1ksim12:06
pgavinI'm rebuilding binutils because I didn't have gdb configured12:06
pgavinstill waiting lol12:06
pgavinthis will probably have to wait until monday though12:08
pgavinhave to leave soon12:08
stekernI can sanity check the repos when I get home, to make sure nothing has broke by recent commits12:10
pgavinwell I telnetted to the jtag port12:11
pgavinand mashed some keys12:11
pgavinand it did *something*12:11
pgavinbut I dont know what :)12:11
blueCmdolofk and I have now laid out the master plan for openrisc for the years to come13:43
blueCmdworld domination is inevitable13:44
Findeton(15:43:57) blueCmd: olofk and I have now laid out the master plan for openrisc for the years to come14:09
FindetonI just joined the room and then you told that14:09
Findetonand now I don't know your plans, do you think that's fair?14:09
blueCmdFindeton: yes, it's fair :)14:09
blueCmdbecause only olofk and I know them!14:09
blueCmdas we did lay them out IRL14:09
Findetonit's not, but anyway I for one welcome the new openrisc overlords14:10
FindetonI think that a multicore openrisc system on a good fpga could bring us a usable openrisc computer14:11
blueCmdno, but yes - a lot of cool things lately that will be very neat when polished14:12
Findetonand I mean, maybe you've read about all the snowden stuff, jacob appelbaum has explained it clearly: basically all computers are compromised14:14
Findetonand if the backdoor is not in the software, it is in the hardware14:14
Findetonfirmware, ACPI too14:14
Findetonso I for one would love to have a openrisc desk pc that I can use daily14:15
Findetonyou know, fuck the nsa and all that14:15
blueCmdright, but as heartbleed showed - that is only part of the solution14:16
Findetonwell, I'm quoting appelbaum now, but security is a three poles system right now: the hardware, the software, and the specific configuration14:19
Findetonso we need to get free software, open/free hardware, and the know-how to maintain a proper configuration... just to get a chance at a secure computer14:20
Findetonof course security is not a black and white subject, security is more like a state of mind..14:20
olofkYes. Ever since that Snowden thing I have made sure to double rot13-encrypt all my traffic.14:22
Findetonolofk: I don't know what kind of computer you use, but the most likely situation is that your computer is owned by the nsa anyway14:24
Findetonit doesn't matter if you encrypt it when your computer has a backdoor already14:25
olofkNot even using double encryption? Damn... I thought I would be safe14:26
blueCmdFindeton: do you know what rot13 is? :P14:26
Findetonnow I know haha14:26
Findetoncaesar encryption haha14:26
blueCmdrot13(rot13(a)) = a14:27
Findetoni've been rick-rolled14:27
blueCmdfun times14:27
Findetoncan we trust the makers of our fpga boards? :/14:27
olofkNot more than we can trust intel or arm to make our CPUs14:28
olofkSo I'm saying that an Open Source computer for the sake of security ain't that much of a win14:28
Findetonolofk: well there is the added advantage that a fpga is too general for them to be able to anticipate how we are going to use it and install backdoors... and we can also use different fpgas to implement the same open source computer14:30
Findetonso there IS  a silver lining :p14:30
blueCmdFindeton: well, they make the synth tools14:33
Findetonis there any open source fpga board (and its tools too) ?14:34
olofkThere are several boards with the PCB layout open source, but I don't think that would make any difference14:37
olofkAnd one could argue that a CPU is also too general to be used for planting back doors. I mean, how would you extract the data?14:38
olofkBut I could have been bought by NSA to say this :)14:38
olofkActually, I think that an open source keyboard would make more sense if someone is paranoid about security14:41
olofkPlenty of room to plant a transmitter, a lot smaller data set and everything is in clear text14:43
olofkOr in your monitor14:43
olofkBut the old-fashioned way to retrieve data from someone is still the most effective
blueCmdolofk: you seem to have a lot of experience in this!14:44
olofkblueCmd: Hand over your cell phone and computer to the guys in black suits that will enter your hotel room in 37 seconds. Please don't make any resistance14:45
olofkThey are your friends14:46
olofkI have already scanned you today with my Multiple Automatic Java Analyzer (M.A.J.A)14:48
olofkOh well. I'm still all for building an Open Source computer.14:57
olofkAnd now we can even use it to play Monkey Island without the NSA listening in on us :)14:57
blueCmdaha! she's a drone!15:00
blueCmdolofk: well... so I haven't exactly updated the openssl in our debian repository ..15:01
olofkblueCmd: OMG! HEARTBLEED!!!!!15:02
olofkOr is it using an 0.98 version?15:02
olofkblueCmd: Yes. She's a drone. Didn't you see when I extracted data from her back door? ;)15:03
olofkSorry about that15:12
stekernhow does all discussions in #openrisc end up in either: 1) discussions about autoexec.bat 2) onani 3) excrements ?15:13
olofkIndeed. Lots of shit talking here15:14
stekernindeed, there are gems when you dig through it though15:15
stekernliterally lol15:16
stekernis that what you cool parents call potty training nowdays?15:17
olofkYep. It's automated to a batch job now15:19
olofkstekern: noob question #35472. How does the caches on e.g. mor1kx access the memories15:55
olofkIs it always a burst of the same size (like cache lock size or whatever it's called15:56
olofkI'm interested in pursuing an idea that I saw in a MicroBlaze based SoC where they had made the memory bus really wide so that you could fill a cache line in one transaction15:57
olofkBecause if you have a wide ddr2 bus you get a lot of data in paralell there15:58
olofkThe atlys board for example has a 16-bit ddr2 IF, which means you get 4*16=64 bits of data for each mem access, but we can only read it into the CPU 32 bits at a time16:00
stekernyes, this is something I have been thinking about too, adding support for wider wishbone bus (like 64-bit, or even wider)16:03
stekernbut, to answer your question - yes, it does bursts of the same size16:04
stekernactually, that is set in the bus interface16:04
olofkFor a longer burst where latency has been amortized we would double the bandwidth16:04
stekernbut that's just an implementation detail, the important part is that it's a fixed burst size16:05
olofkNot having checked the implementation, would it "just" be to edit the cache and wb_if parts16:05
olofkAnd let it be transparent for the CPU itself16:06
stekernI think it should be completely done in the bus if16:06
stekern...and I also think it should be possible to do that ;)16:06
stekernwell, maybe you can make it even more efficient if you change the fetch and lsu bus interface ports16:07
olofkFor the super fancy board that blueCmd has ordered it would make an even bigger impact since he will get 256 bits per access16:08
olofk(64 bit DDR3)16:08
olofkI haven't thought about how resize-friendly the wb bus is. We might have to make the CPU <-> MEM connection point to point without any arbiters16:09
olofkAh no. It should just be to set the sel mask correctly, right?16:10
stekernbut, thinking a bit more about it, it doesn't matter if the cache is actually filled in "one go" or word by word, as long as the burst can provide data at each clock cycle16:11
stekernsince, the processor can't really process more data then a word at each clock cycle16:11
stekernlet's just go dual issue, then we would be able16:12
olofkgtg. Let's think about this some more16:13
stekernthat said, I think there's still performance gains to be able to use wider buses16:13
-!- Netsplit *.net <-> *.split quits: hno`16:26
-!- Netsplit over, joins: hno`16:38
blueCmdstekern: everybody knows that only the special kids ride the short buses16:39
stekernhmm, can't say I knew that...17:05
stekernwhat about the narrow buses then, what kind of kids ride those?17:06
stekernblueCmd: as promised to keep you in the loop, here's the first commit on "SMPing" Linux:
stekernthe ned purpose of this is to get rid of the non-smp compatible exception reg stashing into fixed memory addresses in the 0x0-0x100 area17:20
blueCmdstekern: it needs to be r10 in user space as well18:26
blueCmdor you will need to recompile everything18:26
blueCmdsince TLS relocations are emitted as offsets to r1018:28
blueCmdhopefully I'm missing something, but I'm not a big fan of changing tls from r10 in userspace unless it can be avoided or is very bad18:31
stekernblueCmd: hmm, ok... that sucks donkey *censured*18:55
stekernbecause... I've considered r10 as reserved for kernel use...18:55
stekernso the idea is that we'd be able to trash it without considering userspace18:56
stekernif it's used in userspace, that will of course not work...18:56
-!- Netsplit *.net <-> *.split quits: hno`18:56
blueCmdstekern: yeah, it's set in each thread and needs to be non-mutated, unless I missed something very fundamental18:58
blueCmdstekern: can't you just use r21 for the scratch reg and use -ffixed-r21 ?18:59
blueCmdor is user space clobbering a problem?18:59
stekernno, since I'm going to trash it in userspace18:59
blueCmdyes, that sucks18:59
stekernthat was the beauty of r10, it was our only kernel reg, and you stole it! ;)18:59
blueCmdI guess you could implement a winodw over r10 that makes it "two" registers, one for kernel space and one for user space19:01
stekernthe options are not too bright neither... 1) reserve a couple of other kernel regs in gcc 2) go for the "scratch reg" sprs, or shadowed regs or whatever19:01
stekern1) breaks userspace ABI19:02
blueCmd1) it isn't _that_ huge of a problem19:02
stekern2) sucks equally, since it breaks linux on about every prior implementation19:02
blueCmdI can agree on doing a survey of r21 usage and recompile packages that use it19:02
blueCmdchanging r10 would be almost all packages, r21 probably not so much19:03
stekernunless you ifdef it into a hideous mess19:03
stekernif we're pinning down kernel scratch regs, I'd propose 219:03
stekernbecause that would make things a lot less messy19:04
blueCmd2? as in two?19:04
blueCmdor r2?19:04
stekernyes as in two19:04
blueCmdbecause f* you if r2 :)19:04
stekernhaha, no, I'm not that evil19:04
blueCmdsometimes I wonder..19:05
blueCmdbut yes, I'm all for pinning down more regs19:05
blueCmdI'll script something that objdumps all binaries and surveys which regs are best19:05
-!- Netsplit over, joins: hno`19:07
blueCmdstekern: btw, I think I have all __sync and __atomics covered now. seems implementing X_and_fetch, fetch_and_X and cas seems to be enough19:07
blueCmdI haven't written the implementation, but I'm emitting l.nop instead of the call now, and I've compiled the test suite without gcc throwing up in my face as it usually do, so it seems happy :)19:08
blueCmdI'm a bit worried how to tell gcc that it shouldn't move l.lwa and l.swa from eachother, I figure it might want to do that19:09
stekernhmm, but isn't the __sync and __atomics considered as an "entity"?19:10
blueCmdno! this might be the only part in gcc that is implemented sensibly19:11
blueCmdit tries __atomic first, the __sync, then tries to decompose it into an alternative implementation using __atomic, then __sync and failing that it will emit the libcall19:12
blueCmdand using those I listed as "tier 1", I haven't found any builtins that has reverted to libcalls19:12
-!- Netsplit *.net <-> *.split quits: hno`19:21
stekernbut the biggest problem with 1) isn't actually that we'd have to rebuild a "couple" of packages, the bigger problem is that we break userspace.19:25
stekern...maybe option 2 is the way forward anyway...19:30
blueCmdstekern: for option 1, what happens if I change the 'reserved' reg?19:31
blueCmdin userspace19:31
stekernfor the tls stuff you mean?19:32
blueCmdstekern: forget tls19:32
-!- Netsplit over, joins: hno`19:32
blueCmdlet's say someone clobbers the register while in userspace (which is possible)19:32
stekernwhich register?19:33
blueCmdr10, if you got it your way19:33
stekernok, right19:33
stekernif someone clobbers it in userspace, then userspace will get sad19:33
stekernthe kernel doesn't care what userspace does with it19:34
blueCmdah right19:34
blueCmdso basically it's a reg that can get clobbered anytime, got it19:34
blueCmdyeah, special regs sounds like the way to go there - if we start reserving a lot of regs for stuff it feels like intruding on the ISA/spec19:35
blueCmdbut I have no idea the amount of work involved for that19:35
blueCmdqemu shouldn't care if we do it that way, so there's that19:35
blueCmdnow, dinner19:35
-!- Netsplit *.net <-> *.split quits: hno`19:43
-!- Netsplit over, joins: hno`19:54
-!- FreezingAlt is now known as FreezingCold20:04
-!- Netsplit *.net <-> *.split quits: hno`20:10
olofkAbout multicore interrupt handling. Not sure if I have understood the issue completely, but would it help to have an external interrupt controller here?20:22
olofkAnd just have a single interrupt line in to the CPU20:22
olofkAlso, regarding wide buses. Wouldn't this be very helpful when you have multiple masters as each master spends less time on the bus20:23
olofkI'm thinking both multicore and DMA20:23
olofkIIRC we are already bandwidth starved with the VGA core, and adding ethernet to that might be making it worse20:24
olofkblueCmd: And what you said matches my experience too. My mom always said that I was special and I went on the short bus20:27
_franck_anyone has ever used cfi_ctrl written by juliusb ? I had to fix something in it to make it work:
olofk_franck_: Haven't tried it, but could it be that he hardcoded things for a certain width of the Flash interface perhaps?20:35
olofkIs that the one in orpsocv2 btw?20:36
olofkOr is it a separate core on OpenCores?20:36
_franck_it took the one in opencores svn20:36
_franck_the problem is how it handles 16bits access on a wb32 bus20:37
olofkBecause there is one in orpsocv2. You should check if they differ20:37
_franck_I'll do that20:38
olofkThere were many bug fixes in the orpsocv2 copies of cores that were never upstreamed20:38
olofkIf you find something I suggest you volunteer to become the cfi_ctrl co-maintainer (still looking for people who wants to take care of the poor orphaned cores :))20:39
_franck_:) is that how you reward guy who fix bugs ??20:41
_franck_well, I might know why we don't have much bug fixes ;)20:42
olofkYeah. No one wants to be the guy who touched it last20:42
olofkOh well. This is why we have the patches directory in fusesoc20:43
stekern_franck_: hmm, that looks like it expects something like the wb_data_resize.v would have been attached on the bus20:56
_franck_yeah I though about this20:56
_franck_but here:
_franck_I didn't see any width adapter. But I should look more carefully21:00
stekernhave you tried with both mor1kx and or1200?21:02
_franck_no, only mor1kx21:03
stekernbecause... might be that or1200 let the bits on [1:0] out21:03
_franck_ah, may be, I'll try with or120021:04
stekern...and mor1kx did too before my l.lwa/l.swa changes21:05
stekernbut I considered that a bug...21:06
stekernwhat does the wb-spec say about that?21:07
_franck_let's try to find out21:07
olofkHa! Good luck finding out anything from that document :)21:07
stekern"For example the array size on a 32-bit data port with BYTE21:08
_franck_I wasn't expecting bit [1:0] to be different than '0'21:08
stekerngranularity is [ADR_O(n..2)]."21:08
olofkWhy don't you ask on the wishbone mailing list?21:08
stekernfrom chapter 2.2.3 under the ADR_O description21:09
stekernso, the cfi core lose ;)21:09
stekernunless it claims to have a 16-bit wishbone interface21:11
stekernthen orpsoc lose21:11
_franck_no, it's a 32 bits interface21:11
stekernunder all circumstances though, the one at most loss is _franck_ that needs to fix it :(21:12
_franck_that's why I vote to have system private patches :) So you can patch a core without getting much attention21:13
_franck_I fixed it and all tests passes (hopefully juliusb has done some good test bench)21:14
olofk_franck_: There's nothing stopping you from pulling a complete core locally in your system :)21:14
_franck_but I could seems suspect :)21:14
blueCmdhow would you guys implement nand?21:17
blueCmdsince afaics we don't have a l.nand21:17
stekernc = a and b; c = c xor 0xffffffff;21:23
_franck_I was like: blueCmd wants to use a NAND device and he's joking telling us we don't have l.nand like he could have say "we don't have a l.spi or l.vga"21:25
stekernhaha, to be honest, that was my first thought too21:26
_franck_or1200 let bits [1:0] on the bus while doing 32 bits access21:26
stekernat least I thought he was speaking about nand flash after the first sentence21:27
--- Log closed Sun May 11 00:00:43 2014

Generated by 2.15.2 by Marius Gedminas - find it at!