IRC logs for #openrisc Friday, 2014-05-16

--- Log opened Fri May 16 00:00:50 2014
stekernjuliusb: I think  you should be able to run about anything on the de0_nano03:46
juliusbstekern: cool. I'm just wondering if it's pretty standard, the memory map etc.07:24
olofkjuliusb: It should be. uart on 0x90000000 and so on07:26
juliusbok cool, thanks07:29
olofkThere is a document somewhere that describes a preferred memory layout but no one seems to remember where it is07:30
_franck__there is something here:,filedetails?repname=orsoc_graphics_accelerator&path=%2Forsoc_graphics_accelerator%2Ftrunk%2Fdoc%2ForpsocSetup.pdf07:33
_franck__chapter 5.507:33
olofk_franck__: Yes. That could be the same table I'm thinking of. I wonder where they got that07:36
olofkjuliusb might be of help here,OpenRISC,0,400407:38
olofkHmm that also says that 0xf0000000 and upwards is cached. Is that really true?07:44
LoneTechthat does not sound accurate. I've seen something about addresses over 1<<31 being uncached, but with the mmu enabled there's finer control07:50
LoneTechheh. power waste; the data cache reads from its ram on every cycle the cache is enabled, not just when it should fetch data, it seems07:52
LoneTech(in or1200)07:54
LoneTechfound it: in or1200_defines.v OR1200_DMMU_CI is the default cache inhibit value from the DMMU block (when the mmu is disabled, whether at synthesis or run time). it's simply bit 31 in the case I saw, meaning >=0x80000000 is uncached07:59
olofkLoneTech: Yes, that's what I thought too08:03
LoneTechof course you could change that define for more complex decisions08:03
juliusbsure, that's some sort of memory map which was hanging around, is it still useful?08:11
LoneTechOR1200_IMMU_CI seems to simply be 0, so if the icache is enabled it will work in the rom range08:16
LoneTechI think a suggested memory map with canonical placements of a bunch of peripherals is a fine thing, but I have no idea how many of those are implemented or have reasonably defined register interfaces08:20
LoneTech.. or for that matter, who needs 16 RTCs, or RTCs that use 1MB of address space.08:38
LoneTechthere's something off about the PIC PLT entry. It assumes the GOT address is in r16.. but which GOT? would there not be one per shared object?10:34
LoneTechoh, the PLT must be for calls *from* this shared object. so the caller has set up that GOT10:37
LoneTechI'm a little slow grokking this10:37
LoneTechbut that means taking the address of a function resolves differently than calling that function. confusing.12:09
LoneTechswa/lwa need a bus watcher to function properly. not sure how easy that is in qemu.. I figure more reasonable in qemu-system than qemu-userspace12:11
blueCmdLoneTech: since qemu doesn't do threading at all, I figured that it will work just fine12:11
blueCmduser-qemu that is12:12
LoneTechprobably most of the time, as userspace programs tend not to interact with hardware directly12:12
stekernLoneTech: the address to the function is in the got, so if you want the adress, you can pick it from there, no?12:17
LoneTechhm. msp430 did not have as elegant instruction encoding as I had expected12:17
LoneTechstekern: once it has been resolved, sure. but not before12:17
LoneTechI guess those relocations have to be marked as resolved early12:18
stekernyeah, that's true12:21
stekernbut, if you •do• reference them, they'll be resolved when loaded12:22
stekernmaybe that's what you meant by early12:23
stekernblueCmd: nice, we should look into clearing the link in the future, but that's fine for the moment I think13:03
stekernLoneTech: I don't think you'll need a bus watcher in qemu, isn't it always emulating a single-core?13:04
-!- Netsplit *.net <-> *.split quits: xlro, pgavin, skip__13:46
-!- Netsplit over, joins: pgavin13:46
blueCmdstekern: yep15:49
blueCmdstekern: we could clear it for syscalls and whatnot to closer emulate the behaviour15:49
stekernblueCmd: fetch!
stekerna kernel with them enabled boots past using them now, so they are not entirely broken at least15:50
stekerniow, foreplay is over, now the actual smp stuff can begin15:51
blueCmdhah, cool! :D15:51
stekernthis is the stub it's hitting now: "BUG: failure at arch/openrisc/kernel/smp.c:17/smp_prepare_cpus()!"15:52
stekernfwiw, this is how our smp.c looks like:
stekernso there still a bit to do =)15:53
stekernfeel free to sanity check the spinlock.h though, there might be dragons there still...15:55
stekernand as a reference, here's where I stole most of the code from and translated it to or1k:
stekern(clear it for syscalls) yeah, I had that in mind as well16:01
blueCmdstekern: for gcc I haven't set any memory barriers for atomic operations. I don't know if they are needed TBH16:13
stekernyeah, at least not for any implementations we have... and I added the note that the l.lwa and l.swa acts as memory barriers as well (which might have been a bad ide, don't know)16:19
stekernbut, I just left them in there as they were in the ARM implementation16:20
wallentothey should be memory barriers19:21
wallentoi.e., you don't need l.msync around them19:21
wallentothat is a relaxed consistency model, only release-consistency is even more relaxed19:23
stekernbut can't there be circumstances where you don't want them to be memory barriers?19:29
stekernor at least, they don't *have* to be19:29
wallentoonly release consistency, which requires high-level barriers then19:30
wallentonamely a "lock" and "unlock" operation19:30
wallentogenerally, I think its a good idea to have both as memory barriers19:30
wallentoI have to rethink if l.swa only is sufficient19:31
wallentobut this is already pretty relaxed, mor1kx is the weakest with total-store-order until now19:31
wallentois there any problem with the memory barrier?19:32
stekernno, probably not, just don't want to close any doors if it's not necessary19:32
wallentoI see, we can generally be open there, I think there are architectures that allow atomics to be out-of-order. I will read over the weekend..19:35
wallentoprincipally we can go for weak consistency, problem is: if we set something like this, people should be aware, that we are far away from sequential consistency, so you cannot assume any order in your code19:37
stekernand I guess we have a lot of code that thinks otherwise already...19:38
wallentountil know they silently expect  that "data = 0xdeadbeef; valid = 1" and "while(valid==0) {} x = data;" works19:38
stekernI don't think the l.msync have been used anywhere...19:38
wallentoalthough the architecture manual doesn't say anything about memory ordering until now19:39
wallentoyes, we should be careful and progressive ;)19:39
stekerneven though the arch spec states that it's mandatory to implement it (as a nop if you don't require it to do anything)19:40
wallentothen we were relaxed already :)19:40
wallentobut atomics are special19:40
wallentoi will read a bit over the weekend, speak you monday!19:41
stekernsure thing, I'll go back to playing with my attempts to boot Linux on the two mor1kx in your multi-core demo ;)19:42
stekernwell, it actually boots now with smp turned on, but the second cpu just sits in a loop doing nothing useful so far19:43
wallentohehe, at least it does not crash the other :)19:44
stekernI bet it'll get a chance to that soon enough19:45
-!- Netsplit *.net <-> *.split quits: rah, ysionneau, xlro22:35
-!- Netsplit *.net <-> *.split quits: skip_, Amadiro, fotis2, wallento, zama, heroux, phoohb, mdeininger, javax, blueCmd, (+23 more, use /NETSPLIT to show all of them)22:36
-!- Netsplit over, joins: rah, ysionneau, xlro, iorivur, Limb, FreezingCold, O01eg, pgavin, skip_, blueCmd (+26 more)22:36
--- Log closed Sat May 17 00:00:52 2014

Generated by 2.15.2 by Marius Gedminas - find it at!