| --- Log opened Fri Jan 24 00:00:07 2014 | ||
| olofk | About 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 |
|---|---|---|
| olofk | Or do we just use an existing and point to a different c library? | 07:26 |
| stekern | we have the or1k-linux toolchain for glibc and or1k-linux-uclibc for uclibc | 07:26 |
| stekern | what happened to github? I can only see a small subset of the openrisc repos now... | 07:30 |
| olofk | stekern: You need to upgrade to github EE | 07:32 |
| olofk | Apparently I need to do that too. Can't figure out how to list all repos | 07:33 |
| stekern | I figured out that it hides all forked repos | 07:37 |
| olofk | aha | 07:39 |
| olofk | All the toolchain stuff is forked from pgavins repos, right? | 07:39 |
| stekern | yes, most of the repos are forked from other repos | 07:39 |
| olofk | can we change that? It would be easier to find all the stuff if the openrisc org is the primary source | 07:41 |
| stekern | you can, by removing and adding the repo | 07: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 |
| olofk | Adding and removing sounds way too risky for me to do, but it sounds like a good idea | 08:34 |
| blueCmd | qemu with binfmt works quite nicely. | 11:30 |
| blueCmd | sudo chroot initramfs /bin/uname -a | 11:30 |
| blueCmd | Linux openrisc-lab 3.12-1-amd64 #1 SMP Debian 3.12.8-1 (2014-01-19) openrisc GNU/Linux | 11:30 |
| blueCmd | but apparently the signal code there is not feeling very well. as soon as a signal is thrown it dies | 11:30 |
| olofk | Continuing my stupid question marathon, when are signals thrown? Is that a request from user space to kernel space? | 11:43 |
| blueCmd | olofk: kernel | 12:19 |
| blueCmd | olofk: you can tell the kernel to signal a process as well, that's what 'kill' does | 12:19 |
| jonibo | stekern: hmmm... I didn't get your question... which assmebly version? | 12:21 |
| jonibo | arch/openrisc/lib ( I think) has the interesting bits | 12:21 |
| jonibo | but openrisc is missing a bunch of the goodies and falls back to generic C versions in lib/ | 12:22 |
| stekern | jonibo: 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 memcpy | 12:24 |
| jonibo | yeah... fair enough... I thought I remembered an existing memcpy but apparently it doesn't exist... just the "user" mem copy functions | 12:24 |
| jonibo | but it _should_ exist :) | 12:24 |
| stekern | ok, good, that mean my grep skills are still sane ;) | 12:25 |
| jonibo | heh... I'm sure they are | 12:25 |
| stekern | yeah, I agree, they _should_ | 12:26 |
| stekern | interestingly enough, my grepping yesterday also showed that arm can be configured to use their memcpy implementation for the copy_to/from_user | 12:27 |
| jonibo | yeah, I think we can do the same... I don't think there's anything paritcularly special there | 12:28 |
| jonibo | haven't looked closer at it though | 12:28 |
| jonibo | i think maybe GCC has the memcpy function (byte-by-byte)... I'm pretty sure I've seen it somewhere | 12:28 |
| stekern | the only special in the copy_to/from_user is the exception_table "trickery" | 12:32 |
| stekern | which seems to be handled here: https://github.com/skristiansson/eco32-linux/blob/master/arch/openrisc/mm/fault.c#L238 | 12:32 |
| jonibo | yeah, but that should be fine for memcpy too because you should simply never hit an exception there... | 12:33 |
| jonibo | I think | 12:33 |
| jonibo | the exception stuff is quite harmless... it only applies if you actually get a page fault at the memory access | 12:33 |
| jonibo | it's quite clever... no? | 12:34 |
| stekern | yes | 12:34 |
| blueCmd | jonibo: how do you track differences between mainline and your repository? | 16:04 |
| jonibo | manually | 16:05 |
| jonibo | something specific you had in mind? | 16:05 |
| blueCmd | right. 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 |
| jonibo | it's the WISHBONE_ENDIANESS thing | 16:06 |
| jonibo | I don't know how to handle it upstream | 16:06 |
| blueCmd | oh | 16:06 |
| blueCmd | care to explain? | 16:06 |
| blueCmd | or point to an explaination | 16:06 |
| jonibo | umm... let's see if I remember | 16:06 |
| jonibo | upstream uses ioread/iowrite functions to access core registers | 16:07 |
| jonibo | but linux always assumes little endian bus | 16:07 |
| jonibo | openrisc implementations use big endian wishbone bus so we need to use iowriteb/ioreadb (I think that's what they are called) | 16:07 |
| jonibo | there's a patch in my repo that adds WISHBONE_ENDIANESS option and does the right thing | 16:07 |
| jonibo | but since the driver is not arch-specific, we need to do something nicer to get it upstream | 16:08 |
| jonibo | there was a suggestion to keep track of endianess in a wishbone-specific version of ioread/iowrite, but it's tricky | 16:08 |
| jonibo | ...so I never completed it | 16:08 |
| jonibo | there's 2 or 3 patches for ethoc in my tree that aren't upstream | 16:08 |
| jonibo | i think they should probably go upstream, except for the endianess one | 16:09 |
| jonibo | something like that.. | 16:09 |
| blueCmd | ah ok | 16:09 |
| _franck_web_ | stekern: didn't you have this problem with the vga_lcd core driver ? | 16:10 |
| jonibo | does vga driver use 32 bit registers? | 16:10 |
| jonibo | most of the opencores devices use 8 bit registers, in which case endianess is moot | 16: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 |
| jonibo | since 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 |
| jonibo | ...it just happens to be for the openrisc implementations that exist today | 16:14 |
| stekern | I worked around the endianness problem by autodetecting it | 16:19 |
| stekern | in vga_lcd core driver | 16:20 |
| _franck_web_ | great, I didn't see that patch in orpsoc-cores. Is it upstream ? | 16:21 |
| stekern | no, in the Linux driver I meant | 16:22 |
| stekern | http://marc.info/?l=linux-kernel&m=138964196610007&w=2 | 16:22 |
| stekern | there's another problem with the endianness, but that's unrelated to the problem that's discussed here | 16:23 |
| stekern | X doesn't honor the FBINFO_FOREIGN_ENDIAN flag | 16:24 |
| _franck_web_ | ok, sorry you said: vga_lcd core *driver* | 16:24 |
| stekern | so, the autodetection works by writing a known value to a register, read it back and compare with what you wrote | 16:29 |
| stekern | if it's not the same, the wrong io function was used | 16:29 |
| stekern | not superelegant but it works... | 16:30 |
| maxpaln | howdy - starting to look to reduce the size of the ORSOC implementation by removing the non-essential stuff | 16:46 |
| maxpaln | to establish a baseline size and performance number (my boss is asking for this!) | 16:46 |
| maxpaln | looking through or1200_defines.v there are quite a lot of things that can be excluded - | 16:47 |
| maxpaln | The FPU takes a lot of resources and should be optional - | 16:47 |
| maxpaln | what about the variour Multiplier/Dividier/ALU options - does anyone know if any of these are essential for the Linux Kernel | 16:48 |
| maxpaln | Trial and error will win out unless anyone has tried this before :-) | 16:48 |
| stekern | maxpaln: you can definetely leave out the fpu, the div and mul can be made optional by kernel config knobs | 16:56 |
| maxpaln | great! | 17:04 |
| stekern | does the lattice target you are targetting have hard multipler? | 17:08 |
| stekern | if it does, disabling the multiplier isn't a huge win I think | 17:08 |
| stekern | s/target/fpga | 17:09 |
| maxpaln | stekern: yep - there is a hard multipler in there. | 17:45 |
| maxpaln | I 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 thing | 17:45 |
| maxpaln | I'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 |
| blueCmd | jonibo: I'm fixing qemu-user signals. I know or1k-linux uses orig_gpr11, I'm having trouble getting the hang of when it helps | 21:55 |
| blueCmd | I 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 solve | 21:56 |
| blueCmd | hah, I got it to work | 22:39 |
| blueCmd | I forgot that r0 is not immutable in the emulator! :) | 22:40 |
| blueCmd | R00=00000c00 | 22:40 |
| _franck_ | do you have "color format" in your GTKWave edit menu ? | 23:04 |
| blueCmd | stekern: to build native gcc, can I do that with 4.8.1 or do I need 4.9 branch? | 23:20 |
| stekern | blueCmd: 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.1 | 23:28 |
| blueCmd | stekern: as long as it is in 4.8.2 that's fine | 23:35 |
| blueCmd | I have forwarded my things to that | 23:35 |
| stekern | if there is a class insn_gen_fn in recog.h instead of a typedef, then it's there | 23:36 |
| stekern | err, struct, not class | 23:37 |
| blueCmd | src/gcc/recog.h:struct insn_gen_fn | 23:38 |
| stekern | yup | 23:38 |
| blueCmd | awesome | 23:38 |
| blueCmd | binutils_2.24-2.1_or1k.deb | 23:40 |
| blueCmd | det ballar ur! | 23:40 |
| stekern | writing syscall handlers is messy... | 23:40 |
| stekern | I can reuse the comment above to what I'm doing at the moment too ;) | 23:41 |
| blueCmd | hah. yes. I scratched my head plenty when fixing qemu | 23:42 |
| * blueCmd has tooo many things to upstream | 23:42 | |
| stekern | the most fun part is that most syscall handlers in other archs are deliberately written in a confusing way, just to make them efficient | 23:44 |
| stekern | or that's at least what I make out from it | 23:44 |
| * stekern is still waiting for a joyful aha-moment | 23:45 | |
| blueCmd | stekern: http://449d2bf952c91a98.paste.se/ | 23:58 |
| --- Log closed Sat Jan 25 00:00:09 2014 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!