| --- Log opened Wed May 21 00:00:57 2014 | ||
| stekern | _franck_: hmm, where is your CFI? | 03:43 |
|---|---|---|
| stekern | and please, do not use SPR_NPC, it's disallowed by the arch spec | 03:44 |
| stekern | ok, the old code assumes that cfi is in 0xf0000000 | 03:47 |
| stekern | it was before SPR_EVBAR existed | 03:47 |
| stekern | is it moved before the "normal" relocation by purpose? | 03:51 |
| stekern | ah, ok. it adds the difference... | 03:55 |
| stekern | _franck_: apart from the SPR_NPC, it looks good to me, please send it to the u-boot list | 05:11 |
| stekern | after you have fixed that | 05:11 |
| _franck__ | stekern: do you think we should check for EVBAR ? | 06:59 |
| _franck__ | why EVBAR has been implemented as an offset and not as an absolute address ? | 07:00 |
| stekern | _franck__: as far as I understood, your code will work in most (sane) cases, without checking for evbar, no? | 07:01 |
| _franck__ | well, the vectors will ever be copied at address 0 | 07:02 |
| stekern | ok, good point, I see what you mean now | 07:03 |
| _franck__ | I'll implement the check but not sure I'll tests the code in all cases | 07:04 |
| _franck__ | to answer your question, my CFI is at 0x93000000 | 07:05 |
| stekern | but... EVBAR is optional, and might cause exceptions on old implementations, so maybe we should still leave that out | 07:05 |
| stekern | yeah, I got how and what your code did, and why the current implementation wouldn't work for you | 07:05 |
| _franck__ | but there is a EVBAR presence flag I think | 07:05 |
| stekern | ah, right | 07:05 |
| stekern | the whole relocate the vectors thing was added by juliusb, and the point of it was to get the cfi working, that's why I was confused at first | 07:06 |
| stekern | (offset) it's not? | 07:08 |
| stekern | I mean, it's an absolute address, not an offset, isn't it? | 07:08 |
| _franck__ | "This optional register can be used to apply an offset to the exception vector addresses" | 07:09 |
| stekern | an absolute address, aligned to [31:13] | 07:09 |
| _franck__ | it's an absolute address | 07:09 |
| _franck__ | added as an offset to 0x100, 0x200 ... | 07:10 |
| stekern | right | 07:10 |
| stekern | what's the problem? ;) | 07:11 |
| _franck__ | there is no :) | 07:11 |
| _franck__ | SR[EPH] is not that usefull since 0xf0000000 could be write to EVBAR | 07:12 |
| stekern | I guess, it could have been 'evbar[31:0] + vectors' instead of 'evbar[31:13] | vectors' | 07:12 |
| _franck__ | (if it exist....) | 07:12 |
| stekern | but implementing that might be more resource wasteful | 07:12 |
| stekern | yeah, evbar deprecates SR[EPH], but we have to keep that for backwards compatibility | 07:13 |
| _franck__ | so now we can move vectors to some internal SRAM to get some speed up (don't know how much it would be) | 07:15 |
| _franck__ | at least if we have 0x2000 bytes of SRAM available | 07:16 |
| stekern | you can probably quite safely skip all the 'reserved' vectors though | 07:18 |
| stekern | so, 0xf00 bytes | 07:18 |
| stekern | olofk: took a 5 second closer look at the cygwin fail, looks like quartus for some reason can't grok set_global_assignment -name SEARCH_PATH | 09:42 |
| stekern | I even tried changing that around and running it outside of cygwin, but it still fails... | 09:43 |
| stekern | I've never used quartus to compile verilog on windows before, so I have no "known to work" project to compare with neither | 09:44 |
| _franck_ | is the arch spec 1.1 "offcial" ? Because none of our many spr-defs.h files is sync to the arch spec 1.1 | 19:59 |
| stekern | well, 1.0 is definitely "official", and 1.1 don't change any SPRs | 20:00 |
| _franck_ | not SPR but it extand SPR content like adding EVBARP | 20:01 |
| _franck_ | in CPUCFGR.... | 20:01 |
| stekern | no, 1.1 doesn't change anything related to SPRs | 20:01 |
| stekern | 1.0 did | 20:02 |
| _franck_ | ah ok so s/1.1/1.0 in what I said | 20:02 |
| _franck_ | :) | 20:02 |
| stekern | yup | 20:02 |
| _franck_ | so spr-defs.h are not sync with spec 1.0 ? | 20:02 |
| stekern | probably not | 20:03 |
| stekern | I'm not sure we even should "sync" it in the various upstream projects, unless you also add something that use the new SPRs | 20:06 |
| _franck_ | agree, just update the file when we need new SPR bits | 20:09 |
| _franck_ | in my case I just update bit definitions for the CPU configuration register | 20:09 |
| stekern | yup | 20:24 |
| olofk | stekern: Hmm.. haven't got a clue how to solve the quartus windows problem | 20:50 |
| olofk | But they use SEARCH_PATH in the SoCKit tutorial .qsf | 20:51 |
| stekern | ah, right, that's a source of inspiration | 20:51 |
| stekern | pgavin`: thanks for responding to that mail | 20:52 |
| stekern | have you got a clue what needs to be done in cgen? | 20:52 |
| stekern | I thought I take a look otherwise... | 20:52 |
| stekern | I would assume the cgen/enum.scm files needs to be changed... | 20:59 |
| stekern | https://sourceware.org/cgi-bin/cvsweb.cgi/~checkout~/src/cgen/enum.scm?rev=1.12&content-type=text/plain&cvsroot=cgen | 21:00 |
| * rah whispers "board requirements" gently near olofk's ear | 21:01 | |
| rah | :-) | 21:02 |
| stekern | ok... I've managed to get it to add 'U' on all the enum values now... | 21:39 |
| stekern | that wasn't my attention though, only on the ones > 0x80000000 | 21:40 |
| stekern | ah, now it works | 21:45 |
| stekern | http://pastie.org/9197217 | 21:46 |
| stekern | s/attention/intention | 22:09 |
| stekern | blueCmd: don't get impatient, I'll get you some SMP patches soon too, but I don't think there'll be any today :( | 22:15 |
| stekern | been struggling with the subtle hang... | 22:15 |
| stekern | and the simple 10 line irqchip patch that has turned into a complete rewrite... | 22:16 |
| --- Log closed Thu May 22 00:00:59 2014 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!