IRC logs for #openrisc Friday, 2015-04-17

--- Log opened Fri Apr 17 00:00:10 2015
daliasstekern, is there a reason for having a specific "GOT reg" ?05:12
daliasdoes it need to be loaded to call into the PLT?05:12
dalias(that wouldn't affect musl for now since has no PLT; the linker optimizes it out)05:13
stekerndalias: yes, the plt entries need to have the got pointer loaded in r1605:15
daliasbleh so or1k is affected by the same issue i wrote about for i386:05:21
daliasand gcc should just drop generating calls to PLT and load the address from the GOT directly05:22
stekernmmm, the call via plt is only useful for lazy binding (which you assert in that ewontfix entry)05:29
daliasand i consider lazy binding deprecated because it precludes bindnow+relro05:37
dalias(and for lots of other reasons)05:37
olofkdalias: I saw that Lennart Poettinger namechecked musl in a new blog post about lazy bindings a few days ago07:37
_franck__how can I tell gcc to _not_ use newlib stuffs ?09:31
_franck__I tried -nostdinc -fno-builtin -ffreestanding09:31
_franck__but my elf still contains newlib functions09:32
_franck__-nostdlib is the answer09:33
stekern_franck__ is compiling a FAQ here me thinks ;)09:35
_franck__I still have eh_frame and .comment sections09:37
_franck__and its in objcopy binary output09:37
_franck__normal ?09:37
_franck__.comment section is not in the binary file09:38
_franck__but .eh_frame is09:39
HeshamI am considering renaming RTEMS/or1ksim BSP, what about generic-or1k or genor1k?10:15
HeshamThe same image for this BSP can run on QEMU, or1ksim. jor1k, and real hardware without any modifications.10:16
olofkHesham: 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
olofkHesham: What's in the or1ksim bsp right now? Any link?10:37
Heshamolofk: The current or1ksim BSP is actually configured to work with 32MB RAM10:37
HeshamUART is almost the same as newlib/libgloss stuff10:38
Heshamolofk: This is for or1ksim BSP stuff
HeshamAnd here goes or1k CPU shared functions that doesn't depend on peripherals and/or boards
HeshamBasically it's one to one match with or1200 and/or mor1kxx cores.10:41
olofkNot sure I have understood the files correctly, but it looks like the only peripheral is an UART10:42
HeshamI only run it RTEMS on mor1kx-based fuseSoC, but I believe it can work on both (or1200 and mor1kx)10:42
HeshamYeah the BSP have drivers and startup files10:42
HeshamConsole and timer for example.10:42
HeshamNo IRQ support (yet).10:43
olofkYeah, it should work on both, but some of the FuseSoC systems might have some bugs that prevents or1200 from working10:43
HeshamLike what?10:43
olofkNot sure10:43
olofkProblem is that not many people use FuseSoC with or1200, so it's probably mostly bitrot10:44
HeshamI can give it a try to see whether it's working or not.10:44
olofkIf you add IRQ support for uart, make sure it's on IRQ2. We have tried to keep that consistent between all systems10:44
HeshamYeah I had some pending work on UART IRQ10:45
olofkAnd for the name, I suggest or1k-generic, but I don't mind any of your suggestions10:45
HeshamBut actually I don't see why do we need IRQ for UART anyway.10:45
olofkWe don't use the IRQ in newlib either, but Linux uses it10:46
HeshamInstead of polling?10:46
olofkYes. It uses polling during boot and then switches to interrupts10:46
Heshammmmmm, 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 them10:47
wallentothats wrong10:48
wallentonewlib also uses uart10:48
olofkwallento: Oh.. sorry. Seems like I'm spreading lies again :)10:48
wallentobut I have a pending work item to also add the normal read without interrupt10:49
olofkAh right. Now I remember10:49
wallentoI 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 had10:49
Heshamwallento: Yeah but I can't see where's or1k_uart_set_read_cb is called10:50
wallentothat has changed thanks to a few beers and months of other stuff :-p10:50
wallentoit is required to be called from userspace10:50
wallentomeans the application that links with it10:50
olofkBeer and time is great for clean room implementations :)10:50
wallentoso you need to register the function responsible for receiving your characters10:51
wallentoits then called from the ISR10:51
Heshamwallento: ah so it's mapped to read system call?10:51
wallentoThe system call is still pending10:52
wallentoit is more like this:10:52
olofkHmm... how does that work really? For example, how do I use scanf and getchar?10:52
wallentoshort: you don't10:52
wallentobut that was never the case10:52
olofkahh :)10:52
wallentothat is another reason to rethink it maybe10:52
wallentoat the moment it is like this: The user calls or1k_uart_init10:53
wallentothen he can write characters to the device10:53
olofkHesham: 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 210:53
wallentoto receive characters from the device he then sets a callback10:53
wallentothis process of registering involves activating the interrupts and registering the upcall as the ISR for IRQ line _or1k_board_uart_IRQ10:54
Heshamolofk: Yeah, I may discuss moving to IRQ instead of polling of necessary.10:54
wallentowhen a character arrives the standard exception_handler routine is called10:54
wallentothat junps to the interrupt handler routine10:54
wallentothat finds the callback wrapper in or1k_uart10:54
wallentothat reads the byte10:55
wallentoand calls the user callback10:55
olofkIt's all very simple :)10:55
Heshamwallento: The or1k_uart is the one who should read the byte right?10:55
wallentoI plan to add: read a character from the FIFO, both blocking and non-blocking10:55
wallentoHesham: yes10:55
HeshamBecause I can't see where the byte is being read at libgloss10:55
wallentoah, thats here:10:56
HeshamSo it's the responsibility of the user to implement or1k_uart10:56
wallento(still browsing github)10:56
HeshamSo for the current newlib/libgloss users can't use scanf now?10:56
wallentothis is the point where we read10:57
wallentono, there is no read syscall10:57
wallentothe question is how to generalize the read syscall10:57
wallentoand we only have uart10:57
wallentoso only stdin10:57
wallentoI think thats the reason we also kept doing uart_read() instead of fscanf10:58
Heshamwallento: Ah, it's clear now. Thanks10:58
wallentobut its easy to add10:58
wallentoI 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_read10:59
HeshamBTW, it's great you got rid of GPL licensed code, it's was a block for RTEMS to the old GPL libgloss/UART code11:00
wallentoyeah, that was also the initiating reason11:01
olofkwallento: or1k_uart_read is approximately getchar(), right?11:01
Heshamwallento: And I tried to compile OptiMSoC, but seems like some if the documentations are outdated, especially for compiling system libraries.11:01
wallentoyes, we are splitting this at the moment11:02
wallentobuild yet another OS11:02
wallentoand for this we needed to change a lot11:02
wallentoI hope we will be done with it end of the month11:02
wallentoin future we will release stuff here:
Heshamwallento: And also here
wallentoahh, missed this one11:03
Hesham" project management wiki " link is broken11:03
wallentowe deprecated it in favor of github11:03
wallentowill change the link and get the site up11:03
HeshamIs there any documentation that I can peek into for lisNoC?11:04
wallentounfortunately not, because it is so simple ;)11:06
HeshamWhat about this one?
HeshamAha, I didn't try to see the code actually.11:06
wallentoIf you have some questions that come to your head, please send me a mail and I will answer them directly11:06
wallentobut the core is simple the router11:06
wallentoI will document this on the new github page then11:07
HeshamThat will be great, thanks :)11:07
wallentothe problem is that nobody ever wanted to use it beside us :)11:07
HeshamIs Fiasco port actually working on OpTimSoC?11:07
wallentoso, great to hear you are interested in it11:07
wallentono, it's still in the process of porting11:08
HeshamI need it actually for my research.11:08
wallentothe code quality is really bad, so I have a second student working on it now11:08
wallentohope he will finish it, ETA is end of July11:08
HeshamOK great. I was thinking of having a simple RISCV core instead of mor1kx there.11:09
HeshamAnd for RTEMS, going SMP on OptimSoC would be great.11:09
HeshamRTEMS SMP is currently a work on progress, so having a flexible SW/HW would be of interest.11:10
HeshamThe major SMP efforts go to leon platforms currently.11:11
wallentothis sounds great!11:11
wallentoOur own OS (codename gzll) is also SMP11:11
wallentoso there is a lot of overlap I suppose11:11
HeshamIf it's not GPL licensed it can be used in RTEMS11:12
HeshamMIT or two clause BSD licenses are OK I think.11:12
HeshamBut first I need to get the existing OptimSoC hardware, SW built and working first.11:13
HeshamSo please let me know when you're finished with the changes and maybe updated docs :)11:14
wallentoyes, I will!11:21
HeshamGreat. Thanks!11:24
_franck__whay or1ksim says "invalid": ?13:07
_franck__that was my copy of or1ksim, something I should broke localy13:18
olofk_franck__: Hmm.. I wonder if that's the same problem I saw a few days ago13:34
olofk_franck__: No, that was a different error
olofk(In my case it works if I compile with gcc instead of as)13:39
daliasolofk, oh?16:31
-!- stan is now known as Guest147619:37
olofkMy not nearly finished hexloader is already over 1kB. I suck at this19:53
olofkI should probably have spent more time working on 4k intros back in the scene days19: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 < 4KB20:25
_franck_I now have a terminal and 1KB already is gone20:26
olofkYou got a terminal in 1kB?!?!20:26
_franck_I do but it does nothing20:26
olofkI got... reading from uart... and... some non-working stuff...and.. well, that's it20:26
_franck_get commands then handler are empty20:26
_franck_are you writing in C ?20:27
olofkNo. asm20:27
olofkMy main motivation for asm is that I want to avoid using any memory20:27
_franck_that's why it's easier for me20:27
_franck_I think we can force gcc to use registers only, not sure20:28
_franck_I mean when using C20:29
olofkoh.. that would be cool20:29
daliasolofk, do you have a link to poettering's post? i couldn't find it20:31
olofkdalias: This is very embarrasing... I mixed up things in my RSS reader and thought that EWONTFIX was his blog. Sorry about that20:34
olofkSo instead I'll say that it was a very interesting article :)20:34
daliasolofk, :)20:35
olofkI thought the subject was a bit more low-level than what he usually writes20:35
_franck_olofk: after some readings I don't think we can force gcc to not use the stack20:35
olofk_franck_: Yeah, that was one of the problems I saw with gcc20:36
olofkRight now I'm making sure to only have two levels of recursion and allocate two registers for the return addresses20:36
_franck_however, 256 bytes for stack should be enough20:38
_franck_I tried
_franck_but it seems it's not supported by our gcc20:38
_franck_could be very helpful20:39
-!- rhythmx_ is now known as rhythmx21:09
-!- CrC-Error is now known as Sockbr21:43
--- Log closed Sat Apr 18 00:00:12 2015

Generated by 2.15.2 by Marius Gedminas - find it at!