IRC logs for #openrisc Friday, 2014-01-24

--- Log opened Fri Jan 24 00:00:07 2014
olofkAbout the toolchains... we have the or1k-elf toolchain for newlib and or1k-linux toolchain for uClibc. Will we need a third toolchain for glibc?07:24
olofkOr do we just use an existing and point to a different c library?07:26
stekernwe have the or1k-linux toolchain for glibc and or1k-linux-uclibc for uclibc07:26
stekernwhat happened to github? I can only see a small subset of the openrisc repos now...07:30
olofkstekern: You need to upgrade to github EE07:32
olofkApparently I need to do that too. Can't figure out how to list all repos07:33
stekernI figured out that it hides all forked repos07:37
olofkAll the toolchain stuff is forked from pgavins repos, right?07:39
stekernyes, most of the repos are forked from other repos07:39
olofkcan we change that? It would be easier to find all the stuff if the openrisc org is the primary source07:41
stekernyou can, by removing and adding the repo07:47
_franck_web_I think that would be better to have openrisc own repos because I think it mess up things when you want to delete the original repo (the one you forked from)08:30
olofkAdding and removing sounds way too risky for me to do, but it sounds like a good idea08:34
blueCmdqemu with binfmt works quite nicely.11:30
blueCmd sudo chroot initramfs /bin/uname -a11:30
blueCmdLinux openrisc-lab 3.12-1-amd64 #1 SMP Debian 3.12.8-1 (2014-01-19) openrisc GNU/Linux11:30
blueCmdbut apparently the signal code there is not feeling very well. as soon as a signal is thrown it dies11:30
olofkContinuing my stupid question marathon, when are signals thrown? Is that a request from user space to kernel space?11:43
blueCmdolofk: kernel12:19
blueCmdolofk: you can tell the kernel to signal a process as well, that's what 'kill' does12:19
jonibostekern: hmmm... I didn't get your question... which assmebly version?12:21
joniboarch/openrisc/lib ( I think) has the interesting bits12:21
jonibobut openrisc is missing a bunch of the goodies and falls back to generic C versions in lib/12:22
stekernjonibo: you mentioned a assembly version memcpy in openrisc linux, but I can't seem to find that, only the __copy_to/from_user, which AFAICT does about what memcpy do, but it's not used for memcpy12:24
joniboyeah... fair enough... I thought I remembered an existing memcpy but apparently it doesn't exist... just the "user" mem copy functions12:24
jonibobut it _should_ exist :)12:24
stekernok, good, that mean my grep skills are still sane ;)12:25
joniboheh... I'm sure they are12:25
stekernyeah, I agree, they _should_12:26
stekerninterestingly enough, my grepping yesterday also showed that arm can be configured to use their memcpy implementation for the copy_to/from_user12:27
joniboyeah, I think we can do the same... I don't think there's anything paritcularly special there12:28
jonibohaven't looked closer at it though12:28
joniboi think maybe GCC has the memcpy function (byte-by-byte)... I'm pretty sure I've seen it somewhere12:28
stekernthe only special in the copy_to/from_user is the exception_table "trickery"12:32
stekernwhich seems to be handled here:
joniboyeah, but that should be fine for memcpy too because you should simply never hit an exception there...12:33
joniboI think12:33
jonibothe exception stuff is quite harmless... it only applies if you actually get a page fault at the memory access12:33
joniboit's quite clever... no?12:34
blueCmdjonibo: how do you track differences between mainline and your repository?16:04
jonibosomething specific you had in mind?16:05
blueCmdright. I have always had problems with getting ethoc to work using mainline and it has worked fined with the git repository, I was thinking of digging into and see if I can figure that out (or if it has been fixed)16:05
joniboit's the WISHBONE_ENDIANESS thing16:06
joniboI don't know how to handle it upstream16:06
blueCmdcare to explain?16:06
blueCmdor point to an explaination16:06
joniboumm... let's see if I remember16:06
joniboupstream uses ioread/iowrite functions to access core registers16:07
jonibobut linux always assumes little endian bus16:07
joniboopenrisc implementations use big endian wishbone bus so we need to use iowriteb/ioreadb (I think that's what they are called)16:07
jonibothere's a patch in my repo that adds WISHBONE_ENDIANESS option and does the right thing16:07
jonibobut since the driver is not arch-specific, we need to do something nicer to get it upstream16:08
jonibothere was a suggestion to keep track of endianess in a wishbone-specific version of ioread/iowrite, but it's tricky16:08 I never completed it16:08
jonibothere's 2 or 3 patches for ethoc in my tree that aren't upstream16:08
joniboi think they should probably go upstream, except for the endianess one16:09
jonibosomething like that..16:09
blueCmdah ok16:09
_franck_web_stekern: didn't you have this problem with the vga_lcd core driver ?16:10
jonibodoes vga driver use 32 bit registers?16:10
jonibomost of the opencores devices use 8 bit registers, in which case endianess is moot16:10
_franck_web_can't remember, but I thinkk stekern had problem with endianess (don't if it is on the processor side or bus side)16:11
jonibosince these cores can sit on other buses (avalon, for example) and even wishbone can be little endian, one can't even assume that the core is big-endian...16:14 just happens to be for the openrisc implementations that exist today16:14
stekernI worked around the endianness problem by autodetecting it16:19
stekernin vga_lcd core driver16:20
_franck_web_great, I didn't see that patch in orpsoc-cores. Is it upstream ?16:21
stekernno, in the Linux driver I meant16:22
stekernthere's another problem with the endianness, but that's unrelated to the problem that's discussed here16:23
stekernX doesn't honor the FBINFO_FOREIGN_ENDIAN flag16:24
_franck_web_ok, sorry you said: vga_lcd core *driver*16:24
stekernso, the autodetection works by writing a known value to a register, read it back and compare with what you wrote16:29
stekernif it's not the same, the wrong io function was used16:29
stekernnot superelegant but it works...16:30
maxpalnhowdy - starting to look to reduce the size of the ORSOC implementation by removing the non-essential stuff16:46
maxpalnto establish a baseline size and performance number (my boss is asking for this!)16:46
maxpalnlooking through or1200_defines.v there are quite a lot of things that can be excluded -16:47
maxpalnThe FPU takes a lot of resources and should be optional -16:47
maxpalnwhat about the variour Multiplier/Dividier/ALU options - does anyone know if any of these are essential for the Linux Kernel16:48
maxpalnTrial and error will win out unless anyone has tried this before :-)16:48
stekernmaxpaln: you can definetely leave out the fpu, the div and mul can be made optional by kernel config knobs16:56
stekerndoes the lattice target you are targetting have hard multipler?17:08
stekernif it does, disabling the multiplier isn't a huge win I think17:08
maxpalnstekern: yep - there is a hard multipler in there.17:45
maxpalnI agree that it should be in there - but I've been asked to put together a set of utilisation figures: min, typ and max sort of thing17:45
maxpalnI've found the .config switches now so I can readily compare utilisation and check that everything still works :-)17:46
olofk_maxpaln: I remember hearing some time ago that Lattice has wishbone busses in the silicon of some FPGAs. Can you provide some insight?21:49
blueCmdjonibo: I'm fixing qemu-user signals. I know or1k-linux uses orig_gpr11, I'm having trouble getting the hang of when it helps21:55
blueCmdI want to implement it in qemu-user since I believe I'm having some register smashing with the combination syscall + signal, which if I'm not mistaken is what that tries to solve21:56
blueCmdhah, I got it to work22:39
blueCmdI forgot that r0 is not immutable in the emulator! :)22:40
_franck_do you have "color format" in your GTKWave edit menu ?23:04
blueCmdstekern: to build native gcc, can I do that with 4.8.1 or do I need 4.9 branch?23:20
stekernblueCmd: hmm, the patch that fixes it should have been backported to 4.8.x but I'm not sure if it's in our 4.8.123:28
blueCmdstekern: as long as it is in 4.8.2 that's fine23:35
blueCmdI have forwarded my things to that23:35
stekernif there is a class insn_gen_fn in recog.h instead of a typedef, then it's there23:36
stekernerr, struct, not class23:37
blueCmdsrc/gcc/recog.h:struct insn_gen_fn23:38
blueCmddet ballar ur!23:40
stekernwriting syscall handlers is messy...23:40
stekernI can reuse the comment above to what I'm doing at the moment too ;)23:41
blueCmdhah. yes. I scratched my head plenty when fixing qemu23:42
* blueCmd has tooo many things to upstream23:42
stekernthe most fun part is that most syscall handlers in other archs are deliberately written in a confusing way, just to make them efficient23:44
stekernor that's at least what I make out from it23:44
* stekern is still waiting for a joyful aha-moment23:45
--- Log closed Sat Jan 25 00:00:09 2014

Generated by 2.15.2 by Marius Gedminas - find it at!