| --- Log opened Fri May 16 00:00:50 2014 | ||
| stekern | juliusb: I think you should be able to run about anything on the de0_nano | 03:46 |
|---|---|---|
| juliusb | stekern: cool. I'm just wondering if it's pretty standard, the memory map etc. | 07:24 |
| olofk | juliusb: It should be. uart on 0x90000000 and so on | 07:26 |
| juliusb | ok cool, thanks | 07:29 |
| olofk | There is a document somewhere that describes a preferred memory layout but no one seems to remember where it is | 07:30 |
| _franck__ | there is something here: http://opencores.org/websvn,filedetails?repname=orsoc_graphics_accelerator&path=%2Forsoc_graphics_accelerator%2Ftrunk%2Fdoc%2ForpsocSetup.pdf | 07:33 |
| _franck__ | chapter 5.5 | 07:33 |
| olofk | _franck__: Yes. That could be the same table I'm thinking of. I wonder where they got that | 07:36 |
| olofk | juliusb might be of help here http://opencores.org/forum,OpenRISC,0,4004 | 07:38 |
| olofk | Hmm that also says that 0xf0000000 and upwards is cached. Is that really true? | 07:44 |
| LoneTech | that does not sound accurate. I've seen something about addresses over 1<<31 being uncached, but with the mmu enabled there's finer control | 07:50 |
| LoneTech | heh. power waste; the data cache reads from its ram on every cycle the cache is enabled, not just when it should fetch data, it seems | 07:52 |
| LoneTech | (in or1200) | 07:54 |
| LoneTech | found 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 uncached | 07:59 |
| olofk | LoneTech: Yes, that's what I thought too | 08:03 |
| LoneTech | of course you could change that define for more complex decisions | 08:03 |
| juliusb | sure, that's some sort of memory map which was hanging around, is it still useful? | 08:11 |
| LoneTech | OR1200_IMMU_CI seems to simply be 0, so if the icache is enabled it will work in the rom range | 08:16 |
| LoneTech | I 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 interfaces | 08:20 |
| LoneTech | .. or for that matter, who needs 16 RTCs, or RTCs that use 1MB of address space. | 08:38 |
| LoneTech | there'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 |
| LoneTech | oh, the PLT must be for calls *from* this shared object. so the caller has set up that GOT | 10:37 |
| LoneTech | I'm a little slow grokking this | 10:37 |
| blueCmd | stekern: https://github.com/bluecmd/or1k-qemu/commit/8891b35135f4860732ba87b4831280fdf50b9da5 | 11:55 |
| LoneTech | but that means taking the address of a function resolves differently than calling that function. confusing. | 12:09 |
| LoneTech | swa/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-userspace | 12:11 |
| blueCmd | LoneTech: since qemu doesn't do threading at all, I figured that it will work just fine | 12:11 |
| blueCmd | user-qemu that is | 12:12 |
| LoneTech | probably most of the time, as userspace programs tend not to interact with hardware directly | 12:12 |
| stekern | LoneTech: the address to the function is in the got, so if you want the adress, you can pick it from there, no? | 12:17 |
| LoneTech | hm. msp430 did not have as elegant instruction encoding as I had expected | 12:17 |
| LoneTech | stekern: once it has been resolved, sure. but not before | 12:17 |
| LoneTech | I guess those relocations have to be marked as resolved early | 12:18 |
| stekern | yeah, that's true | 12:21 |
| stekern | but, if you •do• reference them, they'll be resolved when loaded | 12:22 |
| LoneTech | ok | 12:23 |
| stekern | maybe that's what you meant by early | 12:23 |
| LoneTech | yes | 12:23 |
| stekern | blueCmd: nice, we should look into clearing the link in the future, but that's fine for the moment I think | 13:03 |
| stekern | LoneTech: 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: pgavin | 13:46 | |
| blueCmd | stekern: yep | 15:49 |
| blueCmd | stekern: we could clear it for syscalls and whatnot to closer emulate the behaviour | 15:49 |
| stekern | blueCmd: fetch! http://git.openrisc.net/cgit.cgi/stefan/linux/commit/?h=smp&id=f5ab05e2aa059e9f805595bbf9e385a060b646c4 | 15:50 |
| stekern | ;) | 15:50 |
| stekern | a kernel with them enabled boots past using them now, so they are not entirely broken at least | 15:50 |
| stekern | iow, foreplay is over, now the actual smp stuff can begin | 15:51 |
| blueCmd | hah, cool! :D | 15:51 |
| stekern | this is the stub it's hitting now: "BUG: failure at arch/openrisc/kernel/smp.c:17/smp_prepare_cpus()!" | 15:52 |
| stekern | fwiw, this is how our smp.c looks like: http://pastie.org/9182108 | 15:53 |
| stekern | so there still a bit to do =) | 15:53 |
| stekern | feel free to sanity check the spinlock.h though, there might be dragons there still... | 15:55 |
| stekern | and as a reference, here's where I stole most of the code from and translated it to or1k: http://lxr.free-electrons.com/source/arch/arm/include/asm/spinlock.h | 15:57 |
| stekern | (clear it for syscalls) yeah, I had that in mind as well | 16:01 |
| blueCmd | stekern: for gcc I haven't set any memory barriers for atomic operations. I don't know if they are needed TBH | 16:13 |
| stekern | yeah, 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 |
| stekern | but, I just left them in there as they were in the ARM implementation | 16:20 |
| wallento | they should be memory barriers | 19:21 |
| wallento | i.e., you don't need l.msync around them | 19:21 |
| wallento | that is a relaxed consistency model, only release-consistency is even more relaxed | 19:23 |
| stekern | but can't there be circumstances where you don't want them to be memory barriers? | 19:29 |
| stekern | or at least, they don't *have* to be | 19:29 |
| wallento | only release consistency, which requires high-level barriers then | 19:30 |
| wallento | namely a "lock" and "unlock" operation | 19:30 |
| wallento | generally, I think its a good idea to have both as memory barriers | 19:30 |
| wallento | I have to rethink if l.swa only is sufficient | 19:31 |
| wallento | but this is already pretty relaxed, mor1kx is the weakest with total-store-order until now | 19:31 |
| wallento | is there any problem with the memory barrier? | 19:32 |
| stekern | no, probably not, just don't want to close any doors if it's not necessary | 19:32 |
| wallento | I 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 |
| wallento | principally 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 code | 19:37 |
| stekern | right | 19:37 |
| stekern | and I guess we have a lot of code that thinks otherwise already... | 19:38 |
| wallento | until know they silently expect that "data = 0xdeadbeef; valid = 1" and "while(valid==0) {} x = data;" works | 19:38 |
| stekern | I don't think the l.msync have been used anywhere... | 19:38 |
| wallento | although the architecture manual doesn't say anything about memory ordering until now | 19:39 |
| wallento | yes, we should be careful and progressive ;) | 19:39 |
| stekern | even 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 |
| wallento | mmh | 19:40 |
| wallento | then we were relaxed already :) | 19:40 |
| wallento | but atomics are special | 19:40 |
| wallento | i will read a bit over the weekend, speak you monday! | 19:41 |
| stekern | true | 19:41 |
| stekern | sure thing, I'll go back to playing with my attempts to boot Linux on the two mor1kx in your multi-core demo ;) | 19:42 |
| stekern | well, it actually boots now with smp turned on, but the second cpu just sits in a loop doing nothing useful so far | 19:43 |
| stekern | =) | 19:43 |
| wallento | hehe, at least it does not crash the other :) | 19:44 |
| stekern | I bet it'll get a chance to that soon enough | 19:45 |
| -!- Netsplit *.net <-> *.split quits: rah, ysionneau, xlro | 22: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 irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!