IRC logs for #openrisc Wednesday, 2014-05-21

--- Log opened Wed May 21 00:00:57 2014
stekern_franck_: hmm, where is your CFI?03:43
stekernand please, do not use SPR_NPC, it's disallowed by the arch spec03:44
stekernok, the old code assumes that cfi is in 0xf000000003:47
stekernit was before SPR_EVBAR existed03:47
stekernis it moved before the "normal" relocation by purpose?03:51
stekernah, 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 list05:11
stekernafter you have fixed that05: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 007:02
stekernok, good point, I see what you mean now07:03
_franck__I'll implement the check but not sure I'll tests the code in all cases07:04
_franck__to answer your question, my CFI is at 0x9300000007:05
stekernbut... EVBAR is optional, and might cause exceptions on old implementations, so maybe we should still leave that out07:05
stekernyeah, I got how and what your code did, and why the current implementation wouldn't work for you07:05
_franck__but there is a EVBAR presence flag I think07:05
stekernah, right07:05
stekernthe 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 first07:06
stekern(offset) it's not?07:08
stekernI 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
stekernan absolute address, aligned to [31:13]07:09
_franck__it's an absolute address07:09
_franck__added as an offset to 0x100, 0x200 ...07:10
stekernwhat's the problem? ;)07:11
_franck__there is no :)07:11
_franck__SR[EPH] is not that usefull since 0xf0000000 could be write to EVBAR07:12
stekernI guess, it could have been 'evbar[31:0] + vectors' instead of 'evbar[31:13] | vectors'07:12
_franck__(if it exist....)07:12
stekernbut implementing that might be more resource wasteful07:12
stekernyeah, evbar deprecates SR[EPH], but we have to keep that for backwards compatibility07: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 available07:16
stekernyou can probably quite safely skip all the 'reserved' vectors though07:18
stekernso, 0xf00 bytes07:18
stekernolofk: took a 5 second closer look at the cygwin fail, looks like quartus for some reason can't grok set_global_assignment -name SEARCH_PATH09:42
stekernI even tried changing that around and running it outside of cygwin, but it still fails...09:43
stekernI've never used quartus to compile verilog on windows before, so I have no "known to work" project to compare with neither09: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.119:59
stekernwell, 1.0 is definitely "official", and 1.1 don't change any SPRs20:00
_franck_not SPR but it extand SPR content like adding EVBARP20:01
_franck_in CPUCFGR....20:01
stekernno, 1.1 doesn't change anything related to SPRs20:01
stekern1.0 did20:02
_franck_ah ok so s/1.1/1.0 in what I said20:02
_franck_so spr-defs.h are not sync with spec 1.0 ?20:02
stekernprobably not20:03
stekernI'm not sure we even should "sync" it in the various upstream projects, unless you also add something that use the new SPRs20:06
_franck_agree, just update the file when we need new SPR bits20:09
_franck_in my case I just update bit definitions for the CPU configuration register20:09
olofkstekern: Hmm.. haven't got a clue how to solve the quartus windows problem20:50
olofkBut they use SEARCH_PATH in the SoCKit tutorial .qsf20:51
stekernah, right, that's a source of inspiration20:51
stekernpgavin`: thanks for responding to that mail20:52
stekernhave you got a clue what needs to be done in cgen?20:52
stekernI thought I take a look otherwise...20:52
stekernI would assume the cgen/enum.scm files needs to be changed...20:59
* rah whispers "board requirements" gently near olofk's ear21:01
stekernok... I've managed to get it to add 'U' on all the enum values now...21:39
stekernthat wasn't my attention though, only on the ones > 0x8000000021:40
stekernah, now it works21:45
stekernblueCmd: 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
stekernbeen struggling with the subtle hang...22:15
stekernand 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 2.15.2 by Marius Gedminas - find it at!