| --- Log opened Thu Aug 21 00:00:16 2014 | ||
| poke53281 | blueCmd: Do you think this speed comparison is more or less fair? https://github.com/s-macke/jor1k/wiki/Benchmark-with-other-emulators | 05:42 |
|---|---|---|
| poke53281 | It's hard to compare. Most of the important tools are missing. | 05:43 |
| poke53281 | blueCmd, stekern: http://simulationcorner.net/debian.png | 06:15 |
| poke53281 | finally, I can start into debian. But very slow because of the nfs connection through a bottleneck. | 06:16 |
| maxpaln | ok, so the conclusion is that this is a bug related specifically to the way synplify infers MULTs wider than one DSP slice - I think it is specifically related to our newest device, the ECP5, which is the one used on this board! I'll file it as a bug with our SW group - they can work through the fix with Synpopsys. | 08:59 |
| maxpaln | In the interim, I am going to patch in a fix by directly instantiating our silicon macros, our IPexpress tool gives the right template so this is straight forward. The question becomes how to mirror the existing functionality with the new module. The multiplier itself is striaght forward - the overflow handling is a little more cumbersome. | 09:01 |
| maxpaln | well, actually - looking at it I can just reuse the existing code I think, | 09:01 |
| maxpaln | the signed overflow uses the operands and the result of the mult - both are still available. | 09:02 |
| maxpaln | I see that unsigned overflow isn't implemented yet | 09:02 |
| maxpaln | the interesting thing about our multiplier is that it gives a full 64-bit result. So checking the overflow is pretty straight forward if I understand it correctly, I should just be able to check the upper 32-bits and set the overflow accordingly. That's something for later though... | 09:03 |
| blueCmd | poke53281: woo! \o/ | 09:36 |
| hesham | Hi, I have a problem with printf (it does not emit output after context switches), however, printk is working find when used. RTEMS folks told me the problem is with context switches. Are there any special thing that I should take care when saving/restoring task context. Do I have to save any FPU registers although it's not implemented? I am using or1ksim | 09:46 |
| stekern | hesham: I doubt the FPU has anything to do with it | 09:49 |
| stekern | and it's probably not directly related to printf, but more a generic problem with the context switch that happens to show itself like that | 09:49 |
| blueCmd | can it be a varags thing? | 09:50 |
| hesham | stekern: So, I will have to debug the context switch code again, I was just saving/restoring every register as well as SR, EPCR, EEAR, ESR | 09:50 |
| hesham | blueCmd: I do not think so, RTEMS re-defines printf to printk with the proper varargs stuff | 09:51 |
| stekern | can you point us to the context switch code? | 09:54 |
| hesham | Sure | 09:55 |
| stekern | are you accounting for the red zone? | 09:55 |
| hesham | stekern: That's context switch https://github.com/RTEMS/rtems/blob/master/cpukit/score/cpu/or1k/or1k-context-switch.S | 09:56 |
| hesham | And that's for ISR handling https://github.com/RTEMS/rtems/blob/master/cpukit/score/cpu/or1k/or1k-exception-handler-low.S | 09:56 |
| hesham | stekern: red zone ? | 09:56 |
| stekern | hesham: yes, the first 128 bytes of the stack has to be stepped over | 10:03 |
| stekern | leaf functions might use that without modifying the stack pointer | 10:03 |
| stekern | ...and gcc takes advantage of the fact that there is a red zone in non-leaf functions prologues too | 10:04 |
| stekern | i.e. it stores things on the stack and *then* update the stack pointer | 10:05 |
| hesham | stekern: The first 128 bytes of the task stack, not the whole stack right? | 10:07 |
| hesham | Do you think that might be the problem ? | 10:07 |
| stekern | what is 'whole stack'? | 10:09 |
| stekern | if you don't account for it, then it's most certainly a problem | 10:09 |
| stekern | for instance, in your _ISR_Handler, you might be stepping on the excepted code's stack | 10:10 |
| hesham | RTEMS allocated a big chuck of workspace area for both stack and heap. The tasks is the very high section, please have a look at this blog post -> http://heshamelmatary.blogspot.com/2014/06/rtems-kernel-port-for-openrisc-status.html | 10:11 |
| stekern | I think you misunderstood what I meant with 'the first 128 bytes of the stack', the expression was perhaps a bit vague | 10:12 |
| hesham | In the _ISR_Handler, I am allocating 140 bytes for the task context, dump register to it, then switch to a SW allocated stack for interrupts | 10:12 |
| stekern | the red zone is 128 bytes, counting from the current stack pointer | 10:13 |
| stekern | exception handlers need to step over these 128 bytes (i.e. they are not allowed to store anything there) | 10:13 |
| hesham | Aha, So when I add 140 to the task stack pointer, I am violating this red-zone area? | 10:14 |
| stekern | your current _ISR_Handler store data at sp+0 | 10:14 |
| stekern | yes, you need to adjust the stack pointer sp-=(140+128= | 10:15 |
| hesham | I see | 10:15 |
| stekern | sp-=(140+128) | 10:15 |
| hesham | stekern: please have a look at this code from the BSP https://github.com/RTEMS/rtems/blob/master/c/src/lib/libbsp/or1k/or1ksim/start/start.S | 10:16 |
| hesham | It's the very-early code for exception handling that calls _ISR_Handler | 10:16 |
| hesham | have a look at EXCEPTION_SETUP(vector) macro | 10:16 |
| stekern | right, so you have to step over the 128 bytes already there | 10:16 |
| hesham | From there I can allocate the area for 128 | 10:17 |
| stekern | l.addi r1, r1, -4 => l.addi r1, r1, -132 | 10:17 |
| hesham | Great, I will modify the code and tell you what I got | 10:17 |
| stekern | ...and then of course add that 128 back when you return too | 10:18 |
| hesham | Sure from _ISR_Handler | 10:18 |
| hesham | before l.rfe | 10:18 |
| olof | blueCmd: Happy now? ;) https://github.com/olofk/fusesoc/commit/8504c029f97f001fcd0e37027d17921a370f5d21 | 10:24 |
| maxpaln | WooooHoooo! I have a Linux command prompt!!! :-) | 11:19 |
| blueCmd | olof: woo! :D | 11:20 |
| LoneTech | :) | 11:22 |
| maxpaln | A disproportionate joy from such a little green square :-) | 11:23 |
| blueCmd | maxpaln: :D | 11:26 |
| ysionneau | congratz maxpaln :) | 11:29 |
| stekern | =P | 12:18 |
| maxpaln | newbie linux question: Now I have the mor1kx running I ran a quick test to increase the clock rate. I have shifted from 50 MHz to 75 MHz adjusted the or1ksim.dts file, rebuilt the binary and written it to SPI Flash. However, the UART is still coming out garbled. Is there another place to tell Linux (or the UART) that my clock rate has changed? | 13:54 |
| stekern | maxpaln: no, only in the dts. but you have to change the clk freq at two places in the dts | 14:09 |
| maxpaln | yeah, I've done that - once for the CPU once for the serial port | 14:11 |
| maxpaln | hmmm, curious... I presume the values to use are the clock rates in Hx - i.e 75000000 is 75 MHz | 14:14 |
| maxpaln | they were set to 50000000 before when the clock rate was 50 MHz. very strange! | 14:14 |
| maxpaln | hmm, could this be relevant - in uart-defines.v: | 14:16 |
| maxpaln | http://pastie.org/private/va7uhhfcanyfkir8tjm4g | 14:16 |
| stekern | oh, ok | 14:22 |
| stekern | yeah, remove that ;) | 14:23 |
| stekern | (or adjust it for 75MHz | 14:23 |
| maxpaln | :-) I had just come to the conclusion that this wasn't right - my clock rate may change again so I'm gonna comment the PRESCALER_PRESET_HARD and see if I can get it working via the dts file - that would be better. | 14:24 |
| hesham | stekern: I came across the same problem of GDB frame assertion when accounting for red-zone from _ISR_Handler. Would you remind me about the work-around to get over this (changing some instructions order)? | 14:35 |
| maxpaln | much better :-) | 14:50 |
| maxpaln | Well, several reliable build later I think I am happy that the mor1kx processor is working well! :-) At this stage I think the next step is to shift to the latest ORPSOCv3 - I'll start to look into that tomorrow, with a view to having something up and running next week! | 16:14 |
| poke53281 | blueCmd: I need your help. What's the difference between /pool/main, /debian/pool/main and /debian/pool/contrib ? | 16:22 |
| poke53281 | and the question is, if could already boot into Debian, or did you perform a chroot? | 16:24 |
| blueCmd | poke53281: glibc is kinda broken for Debian, I haven't taken myself time to fix that | 16:40 |
| blueCmd | so it's probably going to lock up and behave oddly | 16:40 |
| blueCmd | http://openrisc.debian.net/debian/README | 16:40 |
| blueCmd | tl;dr: /pool/ contains hacked binaries and stuff that has been manually compiled. /debian/ contains pure stuff that is compiled by build bots | 16:41 |
| poke53281 | Maybe it is broken, but at least bash and some basic tools like apt-get are working. That's enough for me now. | 16:57 |
| poke53281 | or do you mean, that you can't boot because it is broken? | 17:01 |
| blueCmd | poke53281: I cannot start udev | 17:02 |
| blueCmd | which breaks booting | 17:02 |
| poke53281 | udev is part of systemd. Are you talking about systemd or about sysvinit? | 17:03 |
| poke53281 | Ok, udev is probably separated | 17:03 |
| poke53281 | by the debian developers | 17:03 |
| poke53281 | systemd would be cool btw. | 17:07 |
| blueCmd | the same, everything is compiled it's just that glibc that's currently compiled is a bit iffy | 17:11 |
| blueCmd | my nocancel implementation is a bit crashy | 17:11 |
| poke53281 | Hmm, what er the most basic packages for a chroot environment I need to start apt. bash, libc, dpkg, apt, ... Is there a basic "filesystem"-package in debian? | 17:11 |
| poke53281 | You will solve it. I have no doubt. :) | 17:12 |
| blueCmd | poke53281: yeah, I just haven't taken the time to do it | 17:19 |
| blueCmd | poke53281: if you do debootstrap it should give you all 'Essential: yes' packages | 17:19 |
| poke53281 | I am already very happy that you came so far. It's really great, that it works. I will put something together for jor1k sooner or later. | 17:20 |
| blueCmd | poke53281: http://openrisc.debian.net/tmp/apt.png | 17:21 |
| poke53281 | Hmm, Looks doable. | 17:23 |
| blueCmd | poke53281: http://c0cc1fc6b8552eaa.paste.se/ those are the 'Essential' packages | 17:23 |
| poke53281 | Hey thanks. But e2fsprogs are not really essential in my opinion. ;) | 17:24 |
| poke53281 | and diffutils too | 17:24 |
| poke53281 | perl-base is a little bit unfortunate because I think it is big. | 17:25 |
| poke53281 | So I will build a filesystem with those packages. | 17:26 |
| poke53281 | e2fsprogs is probably used during boot to check the filesystem. | 17:27 |
| poke53281 | udev is not in the list. Maybe, it is optional | 17:28 |
| ice9 | is openrisc a physical cpu chip? | 21:32 |
| E11Fangirl | OpenRISC is an ISA spec with reference cores. | 21:32 |
| E11Fangirl | People with fabrication capability can implement it in silicon. | 21:32 |
| ice9 | are there any manufactureres selling their chips? | 21:34 |
| E11Fangirl | To the best of my knowledge, not individually. | 21:35 |
| --- Log closed Fri Aug 22 00:00:18 2014 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!
