IRC logs for #openrisc Sunday, 2013-02-03

stekernwoho, three more lines of console output!11:26
stekerni.e. initramfs unpacking passes now11:27
stekernjuliusb: you around?12:00
stekernwhat pic option was the or1200 compliant?12:00
stekernnm, it's LATCHED_LEVEL12:19
stekern*victory ;)12:24
stekernyou know you're a geek when you feel that '!Solid' is a bad name choice for a brand, because it will be interpreted as 'not solid'13:31
stekern(I'm still at the fashion fair in copenhagen)13:32
_franck_stekern: well done with mor1kx14:32
stekern_franck_: thanks14:46
stekernstill a lot of things to do, but this is a leap forward14:46
stekernrunning limux is in itself a pretty good testbench, it brought out a couple of issues that our testsuite didn't catch14:47
stekernI'll look into creating tests for them, but chances are they are to complex to easily reproduce in a test14:49
stekernand fixing one issue makes one test in the testsuite fail, so I have to look into that too14:51
stekernoh, and still only works with icache disabled14:54
stekernwill probably need to patch the kernel to work with VIPT cache14:55
skyfexWhy is ORPSoC for this board not (easily) available?
stekernhmm, actually the kernel might work as is as long as the block+set width <= 13 bits 17:51
stekernso with a 2-way cache, max 16kb cache17:57
juliusbstekern: yes, a weird hybrid of level and edge-triggered interrupts18:10
juliusbVIPT cache?18:11
juliusbskyfex: not sure, on one ever properly released a port I think, but it's rolled into the VM image with development environment for that board you can download I believe18:12
stekernjuliusb: virtually indexed, physically tagged18:49
stekernthe icache is atm18:49
stekernthe dcache will be in the future18:49
stekernwe still have a 1-cycle delay on load/stores into dcache18:50
stekernthe point is that you can do the cache lookup in parallell with the address translation18:57
juliusbah right, cool19:41

Generated by 2.15.2 by Marius Gedminas - find it at!