| --- Log opened Sat Oct 19 00:00:46 2013 | ||
| poke53281 | So, enough spamming for today. If all patches got accepted the QEMU emulator should be much more reliable. | 01:58 |
|---|---|---|
| poke53281 | stekern: What does "external debugger" exactly mean in the specification? In part 4.10 | 02:10 |
| hansfbaier | stekern: What do you think of those commits? Do I need to fix something? The code compiles and works now: https://github.com/openrisc/orpsoc-cores/pull/22 | 02:40 |
| hansfbaier | olofk: ^ | 02:41 |
| stekern | poke53281: that means that reading/writing npc/ppc with mtspr/mfpsr is not guaranteed to be consistent over implementations | 04:23 |
| stekern | i.e. it's not "allowed" to read/write npc/ppc from software | 04:25 |
| poke53281 | Ok, nice | 05:12 |
| poke53281 | So I can remove all this junk from QEMU. | 05:13 |
| hansfbaier | stekern: I have some ideas for orpsocv3: How if we generate orpsoc_top and all wishbone interconnect files with jinja templates? | 05:35 |
| hansfbaier | So every core would have a templates/ subdir | 05:35 |
| hansfbaier | and all the info is in wb_intercon.conf | 05:35 |
| hansfbaier | which I would promote to be the system.conf | 05:35 |
| hansfbaier | or let it as it is? | 05:36 |
| hansfbaier | Then all the user needs to customize is the conf, then all the top and intercon gets generated, so we won't need myriads of `ifdefs, | 05:36 |
| hansfbaier | which make the code unreadable and break anyway with the wb_intercon generator | 05:37 |
| hansfbaier | olofk: dito ^ | 05:37 |
| hansfbaier | olofk: I submitted a pull request for orpsoc, to get familiar with it. | 05:37 |
| hansfbaier | stekern: also with the information from wb_intercon.conf and suitable templates from the individual cores we could autogenerate a dts suitable for the system built | 05:40 |
| Powermaniac | hansfbaier: Are you there as you might be able to answer my questions, although Stekern of Olofk probaly could also | 06:48 |
| hansfbaier | Powermaniac: y | 06:48 |
| hansfbaier | Powermaniac: getting hot now here, i'll be offline soon, so hurry up. | 06:48 |
| Powermaniac | hansfbaier: See I need a sort of way to say how 'finished' ORPSoCv3 is in that you could use it as a system to run say Debian on top of and connect to a HDD, ethernet, usb, wifi etc. | 06:49 |
| hansfbaier | Powermaniac: No distro yet for OpenRISC | 06:49 |
| Powermaniac | hansfbaier: As I have another meeting with UniSA on Monday and they don't seem to understand how far you guys have come since they last looked at OpenRISC. And thus I need to somehow show them that to convince them my idea might be more possible then they realise | 06:50 |
| hansfbaier | Powermaniac: Tell them we have a running Linux system with VGA, sound, ethernet, usb, spi, i2c, jtag, cd card | 06:51 |
| Powermaniac | hansfbaier: Thank you, that is exactly what I needed to know. | 06:51 |
| hansfbaier | Powermaniac: You have no board yet? A de0_nano would be a fantastic low-risc investment, so you could explore on your own. It's only $80. | 06:51 |
| hansfbaier | $50 if you're academic. | 06:52 |
| hansfbaier | s/cd card/sd card/ | 06:52 |
| hansfbaier | usbv1 only | 06:52 |
| Powermaniac | hansfbaier: I'm waiting till Christmas for now. Will be getting the Sockit or DE2 115 or Digilent Atlys though | 06:52 |
| hansfbaier | that was in orpsocv2 | 06:52 |
| hansfbaier | orpsocv2 has no usb yet | 06:52 |
| Powermaniac | Okay | 06:52 |
| hansfbaier | many cores integrated in orpsocv2 aren't in v3 yet | 06:52 |
| hansfbaier | I just ported SPI here: | 06:53 |
| hansfbaier | https://github.com/openrisc/orpsoc-cores/pull/22 | 06:53 |
| Powermaniac | Oh cool | 06:54 |
| hansfbaier | Powermaniac: orpsocv2 is more complete in terms of features ATM, v3 is about the new build system. | 06:54 |
| Powermaniac | Hmm would somone need to make a linux distro from scratch for OpenRISC? | 06:54 |
| hansfbaier | Powermaniac: Yes, somebody has to do that. | 06:55 |
| Powermaniac | As I ahve that crazy idea of using ORPSoCv3 as the base of an open source computer system | 06:55 |
| hansfbaier | Powermaniac: Yocto might be a good thing | 06:55 |
| hansfbaier | Powermaniac: Yocto is a distribution building system | 06:55 |
| Powermaniac | But two of the professor's at UniSA though that wouldn't be possible with my time restraints not realising you guys have already basically made a SoC that is wokring and ready for use. | 06:56 |
| hansfbaier | Powermaniac: Do you want to do this as a thesis or so? | 06:56 |
| Powermaniac | hansfbaier: Okay I shall begin looking into Yocto, would knowing how to program in C first be useful | 06:56 |
| hansfbaier | You probably need C and python | 06:56 |
| Powermaniac | hansfbaier: No I'm just a high school student currently, trying to see if I can go to Uni next year though. | 06:57 |
| Powermaniac | hansfbaier: I have Python down pat so that is good | 06:57 |
| hansfbaier | Powermaniac: I'd advise you to get a de0_nano | 06:57 |
| hansfbaier | Powermaniac: It's cheap and you can do a lot with it | 06:57 |
| hansfbaier | Powermaniac: And very well supported by orpsocv2/3 | 06:58 |
| hansfbaier | Powermaniac: play with it | 06:58 |
| Powermaniac | hansfbaier: See I'm actually in year 11 but have repeated it three times because of illnesses and missing school because of that. Thus it looks like I may not be able to complete year 12 next year because of those illnesses unless I spread it out over 2 years | 06:58 |
| hansfbaier | it's fun | 06:58 |
| Powermaniac | hansfbaier: Or I'm now looking at going straight to university and doing some of it online... | 06:58 |
| Powermaniac | hansfbaier: I might get a De0_Nano depends if I get these laptops that are up for auction or not and what the total cost ends up being as I have a loose $120 sitting around | 06:59 |
| hansfbaier | Powermaniac: That would be great to get started. All you need is a rather recent PC with min. 4GB RAM (better 8) | 07:00 |
| Powermaniac | Got 8GB so that is good. | 07:00 |
| hansfbaier | And a hard disk with about 40GB spare space | 07:00 |
| Powermaniac | Got that too =D | 07:00 |
| hansfbaier | And a usb 2 serial adapter 3V level | 07:00 |
| Powermaniac | Not sure about that though but would that be like a phone charger by any chance? | 07:01 |
| Powermaniac | mini usb phone charger* | 07:01 |
| hansfbaier | http://www.aliexpress.com/item/Free-Shipping-Hot-sell-USB-to-TTL-USB-TTL-9-upgrade-board-STC-microcontroller-programmer-PL2303HX/704553060.html | 07:03 |
| Powermaniac | Oh okay | 07:03 |
| hansfbaier | And this: http://www.aliexpress.com/store/product/80pcs-2-Lot-40pcs-Dupont-wire-cable-Line-1p-1p-pin-connector-20cm-2-54mm-electronic/110055_587221911.html | 07:04 |
| hansfbaier | to connect it to the nano | 07:04 |
| Powermaniac | Okay I shall bookmark those | 07:05 |
| hansfbaier | That with the de0_nano and you have a running Linux system on OpenRISC | 07:11 |
| hansfbaier | getting too hot here now. Time for siesta... | 07:12 |
| hansfbaier | see you around... | 07:12 |
| Powermaniac | Bye and thanks | 07:12 |
| hansfbaier | y/w | 07:12 |
| poke53281 | stekern: I have an interesting problem with the timer in QEMU. In Linux the timer is always in continuous mode. | 07:48 |
| poke53281 | An update of the timer reads TTCR and writes TTCR+delta in TTMR. The distance between both commands is only a few cycles. | 07:48 |
| poke53281 | In QEMU however the timer is realtime. And it looks like between reading TTCR and writing TTMR could be a realtime difference of | 07:48 |
| poke53281 | more than 2ms with the result that I could get an overflow. I think the reason is that the QEMU timer tries to get the time in ns from the kerel. | 07:48 |
| poke53281 | And sometimes the kernel is doing something else in between. This overflow happens very often. Approximately every 20 seconds realtime. | 07:48 |
| poke53281 | I will sleep on this problem. But at the moment I don't have a clue how to solve it. | 07:48 |
| poke53281 | And I found that Linux does not disable the IRQs while updating the timer. | 07:50 |
| rokka | olofk: i am not familiar with tcl scripts, in which file should i add that command? | 09:17 |
| stekern | poke53281: interesting. where in the linux code is the timer updated? | 09:37 |
| stekern | if the timer update isn't "atomic", it sounds to me that bad things might happen on real hardware as well. | 09:38 |
| stekern | fixing that wouldn't help with the qemu problem though... | 09:38 |
| stekern | hansfbaier: yes, automatic top file generation is definitely something we should have | 09:41 |
| stekern | I'm not familiar with jinja templates, will read up on that | 09:41 |
| hansfbaier | stekern: I'm working on the i2c patches | 09:42 |
| hansfbaier | stekern: I have researched a bit, they seemed to be the most powerful for our purpose | 09:42 |
| hansfbaier | lots of nice features | 09:42 |
| stekern | sounds good | 09:42 |
| stekern | because right now, systems aren't as "cheap" as they should be | 09:42 |
| stekern | I would like to have my synth additions to sockit seperate from the 'sockit' system, but right now that would just generate extra maintanance overhead for me, so I keep them in 'sockit' | 09:43 |
| stekern | yes, first impression of jinja, that sounds like something we definitely could use | 09:46 |
| hansfbaier | stekern: good to hear | 09:49 |
| hansfbaier | stekern: don't work on i2c patches, I'm already done | 09:49 |
| hansfbaier | stekern: more on monday, will send you a pull request | 09:49 |
| * hansfbaier gotta go | 09:50 | |
| hansfbaier | bye | 09:50 |
| stekern | olofk: what's your opinion on jinja? | 09:50 |
| stekern | the only con I can come up with is that it is an other dependency | 09:51 |
| -!- Guest64444 is now known as trem | 11:13 | |
| TW__ | Hi friends. Trying to build from a fressh git pull from or1k-src.git. On Ubuntu 13.10/gcc 4.8.1 getting "ld: cannot find -lintl" can't seem to figure out how to get intl library. Any advice? | 15:28 |
| stekern | TW__: might be the last commit that fix a build issue on OSX, could you try to revert that and see if it helps | 16:15 |
| stekern | ? | 16:15 |
| TW__ | stekern: Went back one version (to c5f63b......) and it builds fine. Looks like that last commit is trouble for Linux - at least on my Ubuntu build machine. Thank you for the response. | 16:45 |
| stekern | ok, we'll have to sort that out... thanks for shouting ;) | 16:48 |
| poke53281 | stekern: linux/arch/openrisc/kernel/time.c The first function openrisc_timer_set_next_event | 16:56 |
| poke53281 | The time between mfspr and mtspr could be 2ms under QEMU. | 16:57 |
| poke53281 | And I was wrong. Hardware interrupts are disabled during that time. | 16:58 |
| poke53281 | There could be still a page fault. | 16:59 |
| poke53281 | I have also examples in which the kernel trys to wait only 500 cycles. | 17:26 |
| poke53281 | This could be even on real hardware a problem when there is a page fault. | 17:27 |
| poke53281 | 500 out of 20000000 cycles per second. | 17:27 |
| stekern | poke53281: but then the read and write need to be on different pages, right? | 17:59 |
| poke53281 | Yes | 18:15 |
| poke53281 | The variable c will be a register I hope. | 18:16 |
| poke53281 | So, it's highly unlikely that there will be a problem in real hardware. | 18:34 |
| poke53281 | Ahh, I am getting closer. The problem can be avoided in QEMU. | 18:48 |
| poke53281 | It's nice to see finally correct timings from QEMU. | 19:01 |
| --- Log closed Sun Oct 20 00:00:47 2013 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!