| --- Log opened Fri Apr 17 00:00:10 2015 | ||
| dalias | stekern, is there a reason for having a specific "GOT reg" ? | 05:12 |
|---|---|---|
| dalias | does it need to be loaded to call into the PLT? | 05:12 |
| dalias | (that wouldn't affect musl for now since libc.so has no PLT; the linker optimizes it out) | 05:13 |
| stekern | dalias: yes, the plt entries need to have the got pointer loaded in r16 | 05:15 |
| stekern | https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=bfd/elf32-or1k.c;h=efcefea45425d7f91a9c90ad1c7474a3f8f5d8a1;hb=HEAD#l32 | 05:15 |
| dalias | bleh so or1k is affected by the same issue i wrote about for i386: | 05:21 |
| dalias | http://ewontfix.com/18/ | 05:21 |
| dalias | and gcc should just drop generating calls to PLT and load the address from the GOT directly | 05:22 |
| stekern | mmm, the call via plt is only useful for lazy binding (which you assert in that ewontfix entry) | 05:29 |
| dalias | *nod* | 05:36 |
| dalias | and i consider lazy binding deprecated because it precludes bindnow+relro | 05:37 |
| dalias | :) | 05:37 |
| dalias | (and for lots of other reasons) | 05:37 |
| olofk | dalias: I saw that Lennart Poettinger namechecked musl in a new blog post about lazy bindings a few days ago | 07:37 |
| _franck__ | how can I tell gcc to _not_ use newlib stuffs ? | 09:31 |
| _franck__ | I tried -nostdinc -fno-builtin -ffreestanding | 09:31 |
| _franck__ | but my elf still contains newlib functions | 09:32 |
| _franck__ | -nostdlib is the answer | 09:33 |
| stekern | _franck__ is compiling a FAQ here me thinks ;) | 09:35 |
| _franck__ | :) | 09:36 |
| _franck__ | I still have eh_frame and .comment sections | 09:37 |
| _franck__ | http://pastie.org/10097732 | 09:37 |
| _franck__ | and its in objcopy binary output | 09:37 |
| _franck__ | normal ? | 09:37 |
| _franck__ | .comment section is not in the binary file | 09:38 |
| _franck__ | but .eh_frame is | 09:39 |
| Hesham | I am considering renaming RTEMS/or1ksim BSP, what about generic-or1k or genor1k? | 10:15 |
| Hesham | The same image for this BSP can run on QEMU, or1ksim. jor1k, and real hardware without any modifications. | 10:16 |
| olofk | Hesham: I think we should define some standard Soc components. That would be useful for many situations. Not sure what should go in there though. I think 32MB RAM and UART would be sensible. Maybe GPIO as well. | 10:36 |
| olofk | Hesham: What's in the or1ksim bsp right now? Any link? | 10:37 |
| Hesham | olofk: The current or1ksim BSP is actually configured to work with 32MB RAM | 10:37 |
| Hesham | UART is almost the same as newlib/libgloss stuff | 10:38 |
| Hesham | olofk: This is for or1ksim BSP stuff https://github.com/RTEMS/rtems/tree/master/c/src/lib/libbsp/or1k | 10:39 |
| Hesham | And here goes or1k CPU shared functions that doesn't depend on peripherals and/or boards https://github.com/RTEMS/rtems/tree/master/cpukit/score/cpu/or1k | 10:40 |
| Hesham | Basically it's one to one match with or1200 and/or mor1kxx cores. | 10:41 |
| olofk | Not sure I have understood the files correctly, but it looks like the only peripheral is an UART | 10:42 |
| Hesham | I only run it RTEMS on mor1kx-based fuseSoC, but I believe it can work on both (or1200 and mor1kx) | 10:42 |
| Hesham | Yeah the BSP have drivers and startup files | 10:42 |
| Hesham | Console and timer for example. | 10:42 |
| Hesham | No IRQ support (yet). | 10:43 |
| olofk | Yeah, it should work on both, but some of the FuseSoC systems might have some bugs that prevents or1200 from working | 10:43 |
| Hesham | Like what? | 10:43 |
| olofk | Not sure | 10:43 |
| olofk | Problem is that not many people use FuseSoC with or1200, so it's probably mostly bitrot | 10:44 |
| Hesham | I can give it a try to see whether it's working or not. | 10:44 |
| olofk | If you add IRQ support for uart, make sure it's on IRQ2. We have tried to keep that consistent between all systems | 10:44 |
| Hesham | Yeah I had some pending work on UART IRQ | 10:45 |
| olofk | And for the name, I suggest or1k-generic, but I don't mind any of your suggestions | 10:45 |
| Hesham | But actually I don't see why do we need IRQ for UART anyway. | 10:45 |
| olofk | We don't use the IRQ in newlib either, but Linux uses it | 10:46 |
| Hesham | Instead of polling? | 10:46 |
| olofk | Yes. It uses polling during boot and then switches to interrupts | 10:46 |
| Hesham | mmmmm, I can add support for it, but I'm not sure it would be of much importance to RTEMS, maybe I can discuss this with them | 10:47 |
| wallento | thats wrong | 10:48 |
| wallento | newlib also uses uart | 10:48 |
| wallento | irq | 10:48 |
| olofk | wallento: Oh.. sorry. Seems like I'm spreading lies again :) | 10:48 |
| wallento | but I have a pending work item to also add the normal read without interrupt | 10:49 |
| olofk | Ah right. Now I remember | 10:49 |
| wallento | I did this as i) I needed it and I prefer interrupts over polling, ii) I needed to rewrite from GPL, but still had Jeremy's implementation in the back of my had | 10:49 |
| Hesham | wallento: Yeah but I can't see where's or1k_uart_set_read_cb is called | 10:50 |
| wallento | that has changed thanks to a few beers and months of other stuff :-p | 10:50 |
| wallento | it is required to be called from userspace | 10:50 |
| wallento | "userspace" | 10:50 |
| wallento | means the application that links with it | 10:50 |
| olofk | Beer and time is great for clean room implementations :) | 10:50 |
| wallento | so you need to register the function responsible for receiving your characters | 10:51 |
| wallento | its then called from the ISR | 10:51 |
| Hesham | wallento: ah so it's mapped to read system call? | 10:51 |
| wallento | The system call is still pending | 10:52 |
| wallento | it is more like this: | 10:52 |
| olofk | Hmm... how does that work really? For example, how do I use scanf and getchar? | 10:52 |
| wallento | short: you don't | 10:52 |
| wallento | but that was never the case | 10:52 |
| wallento | :-D | 10:52 |
| olofk | ahh :) | 10:52 |
| wallento | that is another reason to rethink it maybe | 10:52 |
| wallento | at the moment it is like this: The user calls or1k_uart_init | 10:53 |
| wallento | then he can write characters to the device | 10:53 |
| olofk | Hesham: And just to clarify, I'm not saying you should enable interrupts for UART in RTEMS. Just mean that if you, make sure it uses IRQ 2 | 10:53 |
| wallento | to receive characters from the device he then sets a callback | 10:53 |
| wallento | this process of registering involves activating the interrupts and registering the upcall as the ISR for IRQ line _or1k_board_uart_IRQ | 10:54 |
| Hesham | olofk: Yeah, I may discuss moving to IRQ instead of polling of necessary. | 10:54 |
| wallento | when a character arrives the standard exception_handler routine is called | 10:54 |
| wallento | that junps to the interrupt handler routine | 10:54 |
| wallento | that finds the callback wrapper in or1k_uart | 10:54 |
| wallento | that reads the byte | 10:55 |
| wallento | and calls the user callback | 10:55 |
| olofk | It's all very simple :) | 10:55 |
| Hesham | wallento: The or1k_uart is the one who should read the byte right? | 10:55 |
| wallento | I plan to add: read a character from the FIFO, both blocking and non-blocking | 10:55 |
| wallento | Hesham: yes | 10:55 |
| olofk | wallento: | 10:55 |
| Hesham | Because I can't see where the byte is being read at libgloss | 10:55 |
| wallento | ah, thats here: | 10:56 |
| Hesham | So it's the responsibility of the user to implement or1k_uart | 10:56 |
| wallento | (still browsing github) | 10:56 |
| Hesham | So for the current newlib/libgloss users can't use scanf now? | 10:56 |
| wallento | https://github.com/openrisc/newlib/blob/or1k/libgloss/or1k/or1k_uart.c#L104 | 10:56 |
| wallento | this is the point where we read | 10:57 |
| wallento | no, there is no read syscall | 10:57 |
| wallento | the question is how to generalize the read syscall | 10:57 |
| wallento | and we only have uart | 10:57 |
| wallento | so only stdin | 10:57 |
| wallento | I think thats the reason we also kept doing uart_read() instead of fscanf | 10:58 |
| Hesham | wallento: Ah, it's clear now. Thanks | 10:58 |
| wallento | but its easy to add | 10:58 |
| wallento | I would add: a) or1k_uart_read, which only works if no callback is set, b) the read "syscall" that will for the first just wrap or1k_uart_read | 10:59 |
| Hesham | BTW, it's great you got rid of GPL licensed code, it's was a block for RTEMS to the old GPL libgloss/UART code | 11:00 |
| wallento | yeah, that was also the initiating reason | 11:01 |
| olofk | wallento: or1k_uart_read is approximately getchar(), right? | 11:01 |
| Hesham | wallento: And I tried to compile OptiMSoC, but seems like some if the documentations are outdated, especially for compiling system libraries. | 11:01 |
| wallento | yes, we are splitting this at the moment | 11:02 |
| wallento | build yet another OS | 11:02 |
| wallento | and for this we needed to change a lot | 11:02 |
| wallento | I hope we will be done with it end of the month | 11:02 |
| wallento | in future we will release stuff here: https://github.com/optimsoc | 11:03 |
| Hesham | wallento: And also here http://www.lis.ei.tum.de/?id=lisnoc | 11:03 |
| wallento | ahh, missed this one | 11:03 |
| Hesham | " project management wiki " link is broken | 11:03 |
| wallento | we deprecated it in favor of github | 11:03 |
| wallento | thanks | 11:03 |
| wallento | will change the link and get the github.io site up | 11:03 |
| Hesham | Is there any documentation that I can peek into for lisNoC? | 11:04 |
| wallento | unfortunately not, because it is so simple ;) | 11:06 |
| Hesham | What about this one? https://github.com/optimsoc/docs | 11:06 |
| Hesham | Aha, I didn't try to see the code actually. | 11:06 |
| wallento | If you have some questions that come to your head, please send me a mail and I will answer them directly | 11:06 |
| wallento | but the core is simple the router | 11:06 |
| wallento | I will document this on the new github page then | 11:07 |
| Hesham | That will be great, thanks :) | 11:07 |
| wallento | the problem is that nobody ever wanted to use it beside us :) | 11:07 |
| Hesham | Is Fiasco port actually working on OpTimSoC? | 11:07 |
| wallento | so, great to hear you are interested in it | 11:07 |
| wallento | no, it's still in the process of porting | 11:08 |
| Hesham | I need it actually for my research. | 11:08 |
| wallento | the code quality is really bad, so I have a second student working on it now | 11:08 |
| wallento | hope he will finish it, ETA is end of July | 11:08 |
| Hesham | OK great. I was thinking of having a simple RISCV core instead of mor1kx there. | 11:09 |
| Hesham | And for RTEMS, going SMP on OptimSoC would be great. | 11:09 |
| Hesham | RTEMS SMP is currently a work on progress, so having a flexible SW/HW would be of interest. | 11:10 |
| Hesham | The major SMP efforts go to leon platforms currently. | 11:11 |
| wallento | this sounds great! | 11:11 |
| wallento | Our own OS (codename gzll) is also SMP | 11:11 |
| wallento | so there is a lot of overlap I suppose | 11:11 |
| Hesham | If it's not GPL licensed it can be used in RTEMS | 11:12 |
| Hesham | MIT or two clause BSD licenses are OK I think. | 11:12 |
| Hesham | But first I need to get the existing OptimSoC hardware, SW built and working first. | 11:13 |
| Hesham | So please let me know when you're finished with the changes and maybe updated docs :) | 11:14 |
| wallento | yes, I will! | 11:21 |
| Hesham | Great. Thanks! | 11:24 |
| _franck__ | whay or1ksim says "invalid": http://pastie.org/10098162 ? | 13:07 |
| _franck__ | that was my copy of or1ksim, something I should broke localy | 13:18 |
| olofk | _franck__: Hmm.. I wonder if that's the same problem I saw a few days ago | 13:34 |
| olofk | _franck__: No, that was a different error http://pastie.org/10098198 | 13:37 |
| olofk | (In my case it works if I compile with gcc instead of as) | 13:39 |
| dalias | olofk, oh? | 16:31 |
| -!- stan is now known as Guest1476 | 19:37 | |
| olofk | My not nearly finished hexloader is already over 1kB. I suck at this | 19:53 |
| olofk | I should probably have spent more time working on 4k intros back in the scene days | 19:54 |
| _franck_ | olofk: what is your targeted size ? | 20:23 |
| _franck_ | I also started to work on a small bootloader (wrote in C) | 20:24 |
| _franck_ | I'd like to get ethernet to work (tftp) with a binary < 4KB | 20:25 |
| _franck_ | I now have a terminal and 1KB already is gone | 20:26 |
| olofk | You got a terminal in 1kB?!?! | 20:26 |
| _franck_ | I do but it does nothing | 20:26 |
| olofk | I got... reading from uart... and... some non-working stuff...and.. well, that's it | 20:26 |
| _franck_ | get commands then handler are empty | 20:26 |
| _franck_ | are you writing in C ? | 20:27 |
| olofk | No. asm | 20:27 |
| olofk | My main motivation for asm is that I want to avoid using any memory | 20:27 |
| _franck_ | that's why it's easier for me | 20:27 |
| _franck_ | I think we can force gcc to use registers only, not sure | 20:28 |
| _franck_ | I mean when using C | 20:29 |
| olofk | oh.. that would be cool | 20:29 |
| dalias | olofk, do you have a link to poettering's post? i couldn't find it | 20:31 |
| olofk | dalias: This is very embarrasing... I mixed up things in my RSS reader and thought that EWONTFIX was his blog. Sorry about that | 20:34 |
| olofk | So instead I'll say that it was a very interesting article :) | 20:34 |
| dalias | olofk, :) | 20:35 |
| olofk | I thought the subject was a bit more low-level than what he usually writes | 20:35 |
| dalias | np | 20:35 |
| _franck_ | olofk: after some readings I don't think we can force gcc to not use the stack | 20:35 |
| olofk | _franck_: Yeah, that was one of the problems I saw with gcc | 20:36 |
| olofk | Right now I'm making sure to only have two levels of recursion and allocate two registers for the return addresses | 20:36 |
| _franck_ | however, 256 bytes for stack should be enough | 20:38 |
| _franck_ | I tried https://gcc.gnu.org/onlinedocs/gnat_ugn/Static-Stack-Usage-Analysis.html | 20:38 |
| _franck_ | but it seems it's not supported by our gcc | 20:38 |
| _franck_ | could be very helpful | 20:39 |
| -!- rhythmx_ is now known as rhythmx | 21:09 | |
| -!- CrC-Error is now known as Sockbr | 21:43 | |
| --- Log closed Sat Apr 18 00:00:12 2015 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!