IRC logs for #openrisc Thursday, 2014-08-21

--- Log opened Thu Aug 21 00:00:16 2014
poke53281blueCmd: Do you think this speed comparison is more or less fair? https://github.com/s-macke/jor1k/wiki/Benchmark-with-other-emulators05:42
poke53281It's hard to compare. Most of the important tools are missing.05:43
poke53281blueCmd, stekern: http://simulationcorner.net/debian.png06:15
poke53281finally, I can start into debian. But very slow because of the nfs connection through a bottleneck.06:16
maxpalnok, 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
maxpalnIn 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
maxpalnwell, actually - looking at it I can just reuse the existing code I think,09:01
maxpalnthe signed overflow uses the operands and the result of the mult - both are still available.09:02
maxpalnI see that unsigned overflow isn't implemented yet09:02
maxpalnthe 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
blueCmdpoke53281: woo! \o/09:36
heshamHi, 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 or1ksim09:46
stekernhesham: I doubt the FPU has anything to do with it09:49
stekernand it's probably not directly related to printf, but more a generic problem with the context switch that happens to show itself like that09:49
blueCmdcan it be a varags thing?09:50
heshamstekern: So, I will have to debug the context switch code again, I was just saving/restoring every register as well as SR, EPCR, EEAR, ESR09:50
heshamblueCmd: I do not think so, RTEMS re-defines printf to printk with the proper varargs stuff09:51
stekerncan you point us to the context switch code?09:54
heshamSure09:55
stekernare you accounting for the red zone?09:55
heshamstekern: That's context switch https://github.com/RTEMS/rtems/blob/master/cpukit/score/cpu/or1k/or1k-context-switch.S09:56
heshamAnd that's for ISR handling https://github.com/RTEMS/rtems/blob/master/cpukit/score/cpu/or1k/or1k-exception-handler-low.S09:56
heshamstekern: red zone ?09:56
stekernhesham: yes, the first 128 bytes of the stack has to be stepped over10:03
stekernleaf functions might use that without modifying the stack pointer10:03
stekern...and gcc takes advantage of the fact that there is a red zone in non-leaf functions prologues too10:04
stekerni.e. it stores things on the stack and *then* update the stack pointer10:05
heshamstekern: The first 128 bytes of the task stack, not the whole stack right?10:07
heshamDo you think that might be the problem ?10:07
stekernwhat is 'whole stack'?10:09
stekernif you don't account for it, then it's most certainly a problem10:09
stekernfor instance, in your _ISR_Handler, you might be stepping on the excepted code's stack10:10
heshamRTEMS 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.html10:11
stekernI think you misunderstood what I meant with 'the first 128 bytes of the stack', the expression was perhaps a bit vague10:12
heshamIn the _ISR_Handler, I am allocating 140 bytes for the task context, dump register to it, then switch to a SW allocated stack for interrupts10:12
stekernthe red zone is 128 bytes, counting from the current stack pointer10:13
stekernexception handlers need to step over these 128 bytes (i.e. they are not allowed to store anything there)10:13
heshamAha, So when I add 140 to the task stack pointer, I am violating this red-zone area?10:14
stekernyour current _ISR_Handler store data at sp+010:14
stekernyes, you need to adjust the stack pointer sp-=(140+128=10:15
heshamI see10:15
stekernsp-=(140+128)10:15
heshamstekern: 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.S10:16
heshamIt's the very-early code for exception handling that calls _ISR_Handler10:16
heshamhave a look at EXCEPTION_SETUP(vector) macro10:16
stekernright, so you have to step over the 128 bytes already there10:16
heshamFrom there I can allocate the area for 12810:17
stekernl.addi  r1, r1, -4 => l.addi  r1, r1, -13210:17
heshamGreat, I will modify the code and tell you what I got10:17
stekern...and then of course add that 128 back when you return too10:18
heshamSure from _ISR_Handler10:18
heshambefore l.rfe10:18
olofblueCmd: Happy now? ;) https://github.com/olofk/fusesoc/commit/8504c029f97f001fcd0e37027d17921a370f5d2110:24
maxpalnWooooHoooo! I have a Linux command prompt!!! :-)11:19
blueCmdolof: woo! :D11:20
LoneTech:)11:22
maxpalnA disproportionate joy from such a little green square :-)11:23
blueCmdmaxpaln: :D11:26
ysionneaucongratz maxpaln :)11:29
stekern=P12:18
maxpalnnewbie 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
stekernmaxpaln: no, only in the dts. but you have to change the clk freq at two places in the dts14:09
maxpalnyeah, I've done that - once for the CPU once for the serial port14:11
maxpalnhmmm, curious... I presume the values to use are the clock rates in Hx - i.e 75000000 is 75 MHz14:14
maxpalnthey were set to 50000000 before when the clock rate was 50 MHz. very strange!14:14
maxpalnhmm, could this be relevant - in uart-defines.v:14:16
maxpalnhttp://pastie.org/private/va7uhhfcanyfkir8tjm4g14:16
stekernoh, ok14:22
stekernyeah, remove that ;)14:23
stekern(or adjust it for 75MHz14: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
heshamstekern: 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
maxpalnmuch better :-)14:50
maxpalnWell, 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
poke53281blueCmd: I need your help. What's the difference between /pool/main, /debian/pool/main and /debian/pool/contrib ?16:22
poke53281and the question is, if could already boot into Debian, or did you perform a chroot?16:24
blueCmdpoke53281: glibc is kinda broken for Debian, I haven't taken myself time to fix that16:40
blueCmdso it's probably going to lock up and behave oddly16:40
blueCmdhttp://openrisc.debian.net/debian/README16:40
blueCmdtl;dr: /pool/ contains hacked binaries and stuff that has been manually compiled. /debian/ contains pure stuff that is compiled by build bots16:41
poke53281Maybe it is broken, but at least bash and some basic tools like apt-get are working. That's enough for me now.16:57
poke53281or do you mean, that you can't boot because it is broken?17:01
blueCmdpoke53281: I cannot start udev17:02
blueCmdwhich breaks booting17:02
poke53281udev is part of systemd. Are you talking about systemd or about sysvinit?17:03
poke53281Ok, udev is probably separated17:03
poke53281by the debian developers17:03
poke53281systemd would be cool btw.17:07
blueCmdthe same, everything is compiled it's just that glibc that's currently compiled is a bit iffy17:11
blueCmdmy nocancel implementation is a bit crashy17:11
poke53281Hmm, 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
poke53281You will solve it. I have no doubt. :)17:12
blueCmdpoke53281: yeah, I just haven't taken the time to do it17:19
blueCmdpoke53281: if you do debootstrap it should give you all 'Essential: yes' packages17:19
poke53281I 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
blueCmdpoke53281: http://openrisc.debian.net/tmp/apt.png17:21
poke53281Hmm, Looks doable.17:23
blueCmdpoke53281: http://c0cc1fc6b8552eaa.paste.se/ those are the 'Essential' packages17:23
poke53281Hey thanks. But e2fsprogs are not really essential in my opinion. ;)17:24
poke53281and diffutils too17:24
poke53281perl-base is a little bit unfortunate because I think it is big.17:25
poke53281So I will build a filesystem with those packages.17:26
poke53281e2fsprogs is probably used during boot to check the filesystem.17:27
poke53281udev is not in the list. Maybe, it is optional17:28
ice9is openrisc a physical cpu chip?21:32
E11FangirlOpenRISC is an ISA spec with reference cores.21:32
E11FangirlPeople with fabrication capability can implement it in silicon.21:32
ice9are there any manufactureres selling their chips?21:34
E11FangirlTo 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!