--- Log opened Mon Oct 07 00:00:28 2013 | ||
stekern | hansfbaier: no reason, I had to choose one of the two | 04:47 |
---|---|---|
hansfbaier | stekern: thanks. Got the de0_nano today. Did not think it is *that* small | 05:09 |
hansfbaier | stekern: really sweet | 05:09 |
hansfbaier | stekern: Are the meeting slides online yet? I am ready to devour the or1k-Progress report :) | 05:10 |
hansfbaier | mor1kx that is | 05:10 |
hansfbaier | stekern: Another question for orpsocv3/sockit: After building the bootloader, which Linux-Distro can I use, is the factory yocto image fine? | 05:12 |
stekern | hansfbaier: I don't think we've got around to put up the material yet, I know I haven't at least | 05:13 |
hansfbaier | stekern: Another one for the sockit: The qsys contains next to nothing (only HPS and DDR3 controller), is that right? The opencores are mapped in with the tcl I suppose. How do I boot Linux / debug it. Do I have to solder in the JTAG HEADER and disconnect the USB Blaster II? How do you debug that beast? | 05:13 |
stekern | but my slides on the mor1kx update is here: http://oompa.chokladfabriken.org/openrisc/mor1kx.pdf | 05:13 |
hansfbaier | stekern: With: How do I boot Linux, I mean on the OpenRISC, not ARM. | 05:14 |
stekern | as for the rootf, I use this: https://releases.linaro.org/13.04/ubuntu/quantal-images/developer | 05:16 |
hansfbaier | stekern: Cool, does that run X? | 05:17 |
stekern | (qsys) yes, that's right. The orpsoc cores are "mapped in" by orpsoc (look in the orpsoc.core file) | 05:17 |
hansfbaier | stekern: How does X run, I guess I have to add a framebuffer stanza in the dts? | 05:18 |
stekern | it runs X, but you'll need a custom built kernel with the ocfb.c framebuffer driver | 05:18 |
stekern | (from the openrisc tree) | 05:18 |
stekern | (and I have some local changes to that in my local tree) | 05:19 |
hansfbaier | stekern: Is that on the HPS side? and the ocfb is on the FPGA, right? | 05:19 |
hansfbaier | stekern: would be nice to have a branch for that on the kernel tree, would that make sense? | 05:19 |
stekern | http://oompa.chokladfabriken.org/openrisc/ocfb.c <- my current local version | 05:20 |
stekern | nah, I'm planning on trying to upstream the ocfb.c ASAP | 05:20 |
hansfbaier | stekern: I'm a bit confused here. But the kernel is for the HPS, right? | 05:20 |
stekern | yes | 05:20 |
stekern | ok, let's straight things out. ;) | 05:21 |
hansfbaier | What would be the best way to build the kernel? | 05:21 |
stekern | from the HPS side, you have access to all the wishbone peripherals on the FPGA side + the DDR3 on the FPGA side (and it's own DDR3) | 05:21 |
hansfbaier | Install source on ARM and compile on the HPS? | 05:22 |
stekern | from the FPGA side, you have access to the HPS DDR3 | 05:22 |
stekern | so, you can use the framebuffer core from both the HPS and the openrisc side (not at the sime time of course) | 05:23 |
hansfbaier | stekern: Would X/OpenRISC be able to run already? It does so in poke53282's emulator, but probably not for something useful, since there is no OpenRISC distro yet AFAIK | 05:23 |
stekern | yes, I've started X on the sockit (on openrisc) | 05:24 |
stekern | but I don't have a pointing device (or keyboard) for the openrisc side, so it's not very useful on that board (yet) | 05:24 |
stekern | so, regarding which kernel to use on the HPS side. use this git repo: http://git.rocketboards.org/linux-socfpga.git | 05:25 |
stekern | and then you want a kernel > 3.8, since USB OTG is broken on everything < than that | 05:28 |
stekern | I checked out rel_13.07_RC5, which is a 3.9 kernel | 05:29 |
hansfbaier | stekern: Has the linaro any significant advantages over Debian Wheezy? I have a Debian on my flash right now. | 05:29 |
stekern | probably not, I'm a Linux on arm newbie, so I just took what crossed my path first | 05:30 |
LoneTech | juliusb: yes, it's quite possible to run ordb2a with adv_debug, we've done so | 05:30 |
hansfbaier | stekern: How do you boot Linux/OpenRISC and debug it? OpenOCD doesn't do USB Blaster II.... | 05:31 |
stekern | hansfbaier: ok, so to do that I use a small ARM program I wrote to write a binary into the FPGA DDR3 | 05:32 |
stekern | that I promised I would extract from my board for you, but I didn't get around to do that during the weekend | 05:33 |
stekern | I can do that tonight for you | 05:34 |
stekern | but it's not very complex, basically I just mmap FPGA DDR3, byteswap the binary and copy it there | 05:35 |
hansfbaier | stekern: OK, no hurry. But many thanks.... I am done with the labs. Homework done :) | 05:35 |
hansfbaier | stekern: yes, already looked at the examples. | 05:35 |
hansfbaier | stekern: What to do when the DS5-Evaluation-License is expired? | 05:35 |
hansfbaier | stekern: solder in the JTAG header and disconnect the Blaster? | 05:36 |
stekern | and then I use this: https://gist.github.com/mike0/2910170 to flick the reset lines | 05:36 |
stekern | (that memtool is included in the yocto image) | 05:37 |
stekern | it's pretty useful to quickly read/write things from/to the wishbone peripherals | 05:38 |
stekern | I haven't used the DS5, but yes it's a problem that blaster II isn't supported by openocd | 05:38 |
stekern | I did a half-assed effort to reverse engineer it to add support, and made some progress, but never got it finished | 05:40 |
stekern | I have soldered on the jtag header and connected a "normal" usb-blaster to that | 05:40 |
stekern | but I haven't really tested debugging the ARM core with it though | 05:41 |
stekern | ...but, I have an other idea how to solve the debugging of openrisc problem. I want to compile openocd on the ARM and then have some simple regbased access into the openrisc jtag tap | 05:43 |
hansfbaier | stekern: I have an FTDI-based china JTAG (jtagkey) clone here that works quite ok on my Cortex-M3. | 05:43 |
stekern | and then write a custom openocd driver for that reg-based interface | 05:43 |
stekern | then you can just connect gdb from your workstation through the openocd bridge running on the ARM | 05:45 |
hansfbaier | stekern: good idea | 05:45 |
stekern | the only thing I was uncertain about regarding that setup was if openocd would easily be compilable on the ARM, but I asked _franck_ about that during the weekend and he said it's commonly done | 05:46 |
stekern | and the missing usb-blaster ii support in openocd isn't the only reason I'd like to do that, the other reason is that when you connect through the JTAG, it upsets the arm (reset it) | 05:53 |
stekern | not sure if that's because some configuration miss in openocd or if it's unavoidable though... | 05:54 |
hansfbaier | stekern: good to know | 06:00 |
hansfbaier | stekern: Please allow me another question: I have my julius-based locally modified linux-Kernel here running. But if I wanted to move to a newer version (that has the W5100 driver), what would be the recommended revision/tag/branch to go to? | 06:04 |
stekern | umm, define "julius-based locally modified"? | 06:05 |
hansfbaier | stekern: Another last question: Do you get paid for working on OpenRISC? The time and effort you put into this is really monumental... | 06:05 |
hansfbaier | stekern: Wait a moment: git status still running :] | 06:06 |
hansfbaier | based on 065bba63d70b6de4f56c75f5e3a89ac2a5d0b01f | 06:06 |
stekern | hansfbaier: no, I don't get paid for working on openrisc, it's just a hobby | 06:06 |
hansfbaier | stekern: whooaa. Do you ever sleep? | 06:07 |
stekern | no =) | 06:07 |
hansfbaier | stekern: You will die young :) | 06:07 |
hansfbaier | stekern: need at least 6hrs or heart damage ..... | 06:08 |
stekern | hansfbaier: that oppurtunity have almost already past... ;) | 06:08 |
Powermaniac | hansfbaier: You can survive on 3 hours of sleep a day... | 06:10 |
stekern | nah, I think that studies have shown that the sleeprequirements are highly individual | 06:10 |
stekern | there are no such thing as a fixed number that fits all, and specifically not that they have to be done continously | 06:13 |
Powermaniac | stekern: True | 06:14 |
hansfbaier | stekern: where did you get your knowledge about CPU design (see mor1kx slides). Got a recommendation? | 06:15 |
stekern | umm, hacking on mor1kx ;) | 06:15 |
Powermaniac | hansfbaier: Haha I've asked him that question before, and got basically the same response | 06:16 |
hansfbaier | stekern: OK, good to hear. After the 2012 slides I got some appetite for that :) | 06:16 |
stekern | 2012 slides? | 06:17 |
hansfbaier | conference | 06:17 |
olofk | Everyone got home safely? | 06:19 |
stekern | olofk: yup | 06:19 |
olofk | I fixed bug 97 on the flight back home. Nasty little thing. I guess no one has really used l.rori :) | 06:19 |
Powermaniac | olofk: Did you get home safely? | 06:20 |
olofk | Powermaniac: No. I'm still hiding under juliusb bed. Just make sure not to tell him | 06:20 |
Powermaniac | LOL | 06:21 |
stekern | we had some initial exceitement with what train we should jump on, and the switch at kings cross was a bit tight, but otherwise it went smooth | 06:21 |
Powermaniac | Just thought it would be rude not to ask... | 06:21 |
olofk | Actually, the flight was delayed on the way back home, but they managed to catch up enough to play Ryanair's infamous we're-in-time-fanfare | 06:21 |
stekern | *excitement | 06:21 |
olofk | stekern: The whole room was screaming GET ON THE TRAIN when you we're talking to juliusb on the phone :) | 06:22 |
stekern | haha | 06:22 |
stekern | there was some mixed messages about what station we should jump off at too, there was engineering work on the line so they were suggesting some other stations than the hitchin station that juliusb adviced for the switch towards kings cross | 06:24 |
stekern | but after consulting some locals on the train we found out that the hitchin station was still fine for the switch | 06:24 |
olofk | I wouldn't trust getting directions from people who drive on the wrong side of the road | 06:30 |
Powermaniac | Wait what side of the road do you drive on...Australians drive on the left. | 06:33 |
Powermaniac | Oh just checked for myself, right hand traffic in most of Europe... | 06:35 |
Powermaniac | And well most of the world actually | 06:35 |
Powermaniac | More relevant to the channel question: Do you guys use the programming language C often? | 06:37 |
hansfbaier | Powermaniac: If you want to do embedded/kernel development write bare metal applications it's fundamental. | 06:39 |
Powermaniac | hansfbaier: Thought that might be the case, trying to learn C now actually. Ditched Java as well I wasn't getting anywhere with it a while ago now and it turned out it wasn't really used for the things I was interested in. And is also supposedly a 'bad' language | 06:40 |
olofk | Fuck... updated the wrong bug | 06:42 |
olofk | No, it was correct | 06:42 |
hansfbaier | Powermaniac: Java is actually a very useful language, if you want to develop banking applications and/or solid enterprise / web applications | 06:42 |
stekern | Powermaniac: we drive on the right side of the road, not the wrong | 06:43 |
hansfbaier | It's one of the top used languages | 06:43 |
olofk | stekern: :) | 06:43 |
Powermaniac | hansfbaier: Oh okay, I've just been it has a lot of issues... | 06:43 |
hansfbaier | Powermaniac: I made most of my living with Java as an enterprise/web developer | 06:43 |
hansfbaier | Powermaniac: now I'm into embedded and I use C | 06:43 |
Powermaniac | stekern: Haha, I have to wonder why they wouldn't just make right side driving global. Probably too difficult to change now though | 06:43 |
hansfbaier | Those two are good for different things | 06:43 |
hansfbaier | Powermaniac: Indonesia drive on the left too | 06:44 |
Powermaniac | stekern: Probably has something to do with England and the CommonWealth I assume | 06:44 |
hansfbaier | I've converted | 06:44 |
hansfbaier | Powermaniac: don't know. Indonesia was a dutch colony. Where do the dutch drive? | 06:44 |
Powermaniac | hansfbaier: The right, hmm that is weird then | 06:45 |
Powermaniac | hansfbaier: https://en.wikipedia.org/wiki/File:Countries_driving_on_the_left_or_right.svg | 06:45 |
olofk | Powermaniac: Yeah, just some smaller provinces like Australia and India drives on the left side | 06:45 |
Powermaniac | Heh North America originally drove on the left | 06:46 |
Powermaniac | Well The United States I mean | 06:46 |
stekern | yeah, I think many countries have switched, sweden used to drive on the left too | 06:53 |
poke53282 | hansfbaier: X is not useful at the moment. It is working but still unstable. And yes, a distro would be nice. | 06:55 |
poke53282 | At the moment I am thinking of a simple image for or1ksim and QEMU that contains native compiler and tools. | 06:55 |
poke53282 | Then it would be much easier for others to develop something for or1k. | 06:55 |
poke53282 | Since today I can offer you wayland for or1k ... | 06:55 |
poke53282 | well, almost. It compiles without problems, it runs, it reckognizes the framebuffer and the touch screen. It communicates a lot between server, client and compositor. A lot of applications can be started. But the screen remains black ... all the time. And I don't know why. | 06:55 |
hansfbaier | poke53282: Wow, you're really digging in! | 06:56 |
stekern | poke53282: your name was mentioned a numerous couple of times during the conference ;) | 06:59 |
poke53282 | Yes, I expected something like this. The community is not big enough yet :-) . Unfortunately I could come. Mainly because it is too expensive to come from Vancouver | 07:00 |
poke53282 | s/could come/could not come/ | 07:00 |
olofk | poke53282: Wayland? That's so cool. Porting hot applications like that is exactly what's needed to make more people interested | 07:01 |
stekern | poke53282: yes, I understand that, we missed you there still | 07:01 |
olofk | poke53282: Yeah, I can understand that. I've been thinking it would be great to somehow get sponsorship for things like that. We should check how to do that for next year | 07:01 |
poke53282 | olofk: As I said it works basically but the screen is still black. Let's see if I can manage it to run till the end of the week. | 07:01 |
poke53282 | stekern, olofk: Maybe I am back in living Europe next year. | 07:03 |
stekern | we were speaking about potentially having it munich next year | 07:03 |
stekern | +in | 07:03 |
poke53282 | Oh, that would be very easy for me. | 07:04 |
stekern | ...and wayland, way cool! =) | 07:04 |
poke53282 | I have to say that I like wayland much more than X11. The source code by several orders of magnitude smaller and understandable. | 07:05 |
poke53282 | olofk,stekern: And I had to program and libffi implementation for or1k. I will put in on github these days. | 07:07 |
stekern | ah, that's great! I would have needed that for something else some time (but I can't for my life remember what now) | 07:08 |
poke53282 | Java? | 07:08 |
stekern | hmm, I don't think that was it | 07:09 |
stekern | it could have been when I tried to compile irssi | 07:09 |
stekern | it has pretty massive dependencies iirc | 07:10 |
poke53282 | stekern: Tomorrow you can tell me about the decisions about the ABI. Now I have to go to bed. | 07:11 |
poke53282 | Already 12PM. | 07:11 |
stekern | yeah, that's probably it, it depends on glib which depends on libffi | 07:11 |
poke53282 | And I need normally 8 hours ;) | 07:12 |
stekern | sleep well! | 07:12 |
hansfbaier | poke53282: Yes, put it on git, maybe I can help a bit. | 07:14 |
olofk | libffi is really cool too, even if it doesn't directly output pretty pictures on the screen. Should open up a lot of new possibilities | 07:18 |
olofk | I'm thinking java (android?), python and stuff | 07:19 |
_franck_ | stekern: (transport): hopefully we catched that train I arrived quite shortly before the boarding | 07:46 |
_franck_ | and hopefully I didn't follow you to the South Terminal :) | 07:46 |
stekern | you mean "luckily"? ;) | 07:48 |
stekern | did it get tight to catch your flight? | 07:49 |
stekern | obviously you made it ;) | 07:49 |
_franck_ | yeah I made it, I had a 15 min margin :) | 07:52 |
stekern | that's plenty | 07:53 |
stekern | I even had time to buy some souvenirs/candy for the family | 07:53 |
jeremybennett | good morning all. Glad to hear you made it home | 07:55 |
_franck_ | good morning jeremybennett , we were lucky to get some support by phone to make it on time ;) | 07:58 |
Powermaniac | good morning | 07:59 |
jeremybennett | _franck_: The power of modern communications | 07:59 |
jeremybennett | Powermaniac: Good morning | 07:59 |
Powermaniac | So would you all say ORCONF2013 was a success? | 08:18 |
_franck_ | olofk: Warning: Failed to parse ../orpsoc-cores/cores/mor1kx-dev-env/mor1kx-dev-env.core: Could not find API type in ../orpsoc-cores/cores/mor1kx-dev-env/mor1kx-dev-env.core | 08:20 |
_franck_ | it that the new feature ? | 08:20 |
stekern | can't wait to test that "feature" out ;) | 08:38 |
olofk | _franck_: But it still runs, right? | 10:10 |
olofk | Because mor1kx-dev-env doesn't have the API definition, so it should warn, but continue anyway | 10:11 |
stekern | I just handed over the VGA patches to Richard | 10:25 |
olofk | stekern: Cool. Has he responded? | 10:29 |
stekern | when I wrote "just", I meant just. so, no ;) | 10:33 |
stekern | I wouldn't have got it even if he had with the lag from gmails pop3 delay | 10:34 |
Powermaniac | I'm going to assume you guys wouldn't recommend learning C without much programming knowledge in general, would you? | 11:08 |
Powermaniac | As ##programming sure isn;t | 11:08 |
hansfbaier | Powermaniac: You could start with python | 11:09 |
hansfbaier | Powermaniac: python is the visual basic of the linux world | 11:09 |
hansfbaier | Powermaniac: And it is tremendously useful | 11:09 |
Powermaniac | hansfbaier: Yeah that is what I'm looking at now. In particular Learn Python The Hard Way. | 11:09 |
hansfbaier | stekern: Would you mind pasting your kernel config? The 3.7 seems to be very different from the 3.9. I could take the 3.7 kernel that comes with altera, but as you said, that would break USB OTG | 11:11 |
stekern | hansfbaier: oh, sorry, I forgot to mention, just run 'make socfpga_defconfig' | 11:13 |
hansfbaier | stekern: thanks a lot | 11:13 |
hansfbaier | stekern: I probably have to set CROSS_COMPILE="arm-linux-gnueabihf-" with the compiler from the ds-5, right? | 11:15 |
stekern | right | 11:15 |
stekern | and then make ARCH=arm | 11:15 |
hansfbaier | stekern: OK, running | 11:15 |
hansfbaier | stekern: But I probably need a dtb entry for vga_lcd, don't I? | 11:16 |
stekern | make ARCH=arm uImage, to be more precise | 11:16 |
hansfbaier | stekern: thanks again | 11:16 |
stekern | yes, and you ofcourse need to merge in the Kconfig too | 11:17 |
stekern | and enable the driver | 11:17 |
hansfbaier | stekern: already done using obj-y | 11:17 |
hansfbaier | in the Makefile | 11:17 |
hansfbaier | so shoudln't need Kconfig I suppose, or is fb disabled...? | 11:17 |
hansfbaier | # CONFIG_FB is not set | 11:18 |
hansfbaier | oh... ok | 11:18 |
stekern | http://oompa.chokladfabriken.org/openrisc/socfpga_cyclone5.dts | 11:19 |
stekern | http://oompa.chokladfabriken.org/openrisc/Kconfig | 11:19 |
stekern | yeah, it has a couple of 'depends on' | 11:20 |
stekern | errr, select I meant | 11:21 |
stekern | http://oompa.chokladfabriken.org/openrisc/.config | 11:21 |
stekern | that's the config I used, in case I did some additional changes I might have forgot about | 11:22 |
hansfbaier | stekern: thanks a lot | 11:24 |
hansfbaier1 | stekern: drivers/video/ocfb.c: file not recognized: File format not recognized | 11:33 |
stekern | what did you set obj-y to? | 11:35 |
stekern | ocb.o I hope | 11:35 |
stekern | ocfb.o | 11:35 |
_franck_ | olofk: yes, I still works, I just didn't let it finished the first time, I ctrl+c it just after seeing *Failed* | 11:38 |
_franck_ | sorry for the noise | 11:38 |
stekern | hansfbaier: did you set obj-y to ocfb.o? | 11:39 |
stekern | and not ocfb.c? | 11:39 |
hansfbaier | stekern: so it was actually: make ARCH=arm -j12 LOADADDR=0x00008000 uImage | 11:39 |
hansfbaier | stekern: Yes :] stupid mistake. | 11:39 |
stekern | (I've done that by mistake some time) | 11:39 |
hansfbaier | stekern: Makefile habits | 11:39 |
hansfbaier | maybe | 11:40 |
hansfbaier | uImage is done | 11:40 |
* hansfbaier drumroll............... try it | 11:40 | |
stekern | yes, you're right! I forgot about the LOADADDR... good that you found it out anyways | 11:40 |
hansfbaier | stekern: hangs | 11:42 |
hansfbaier | didn't copy device tree yet | 11:42 |
stekern | ah | 11:42 |
stekern | it has otherwise changed from 3.7, so you need that | 11:43 |
stekern | regardless of the ocfb | 11:43 |
hansfbaier | stekern: didn't program fpga too :] | 11:43 |
hansfbaier | stekern: I need to copy it to the uboot partition too, right? | 11:44 |
hansfbaier | as dtb | 11:44 |
stekern | yes | 11:44 |
stekern | reminds me of another thing you'll need to know now when you already enabled the framebuffer | 11:44 |
stekern | you need to enable the hps2fpga bridge, it *should* be done by the kernel somehow (the "stock" 3.7 did that), but I haven't figured out how to enable it in the 3.9 kernel | 11:45 |
stekern | so I just have done it manually in u-boot | 11:46 |
stekern | with: mw 0xffd0501c 4 | 11:47 |
stekern | see http://www.altera.com/literature/hb/cyclone-v/hps.html if you want to know what it means ;) | 11:52 |
stekern | under rstmgr->brgmodrst | 11:53 |
hansfbaier | stekern: IT BOOTS | 11:55 |
stekern | \o/ | 11:55 |
stekern | it's nice to be at that point, where you have a kernel you've compiled yourself that boots | 11:57 |
stekern | any hacking beyond that is just increamental | 11:58 |
hansfbaier | stekern: Ah stale dtb. Had to call make without uImage first | 12:03 |
hansfbaier | stekern: reminds me of good old days transferring files with rz/sz | 12:06 |
stekern | aah, yes. you can make the dtbs alone with 'make dtbs' too | 12:17 |
stekern | there's quite alot of info here that you might be interested of: http://rocketboards.org/ | 12:18 |
hansfbaier | stekern: # find /proc/device-tree/ | grep ocfb | 12:20 |
hansfbaier | /proc/device-tree/soc/ocfb@ff32e000 | 12:20 |
hansfbaier | nice | 12:21 |
stekern | yay | 12:21 |
stekern | do you get any output on the vga output too? | 12:22 |
hansfbaier | stekern: Yes, black | 12:23 |
hansfbaier | [ 95.401] (EE) FBDEV(0): FBIOBLANK: Invalid argument | 12:23 |
hansfbaier | hmmm | 12:23 |
stekern | I get that too, it's "normal" | 12:24 |
hansfbaier | stekern: Oh you mean on boot? | 12:24 |
hansfbaier | stekern: It seems to hang there | 12:24 |
stekern | ? | 12:25 |
stekern | isn't that when it tries to start X | 12:25 |
hansfbaier | stekern: Yes, starting X | 12:25 |
hansfbaier | wait a minute | 12:25 |
hansfbaier | stekern: No penguin on VGA on boot. | 12:26 |
stekern | to do it correctly, you should pass video=ocfb:640x480-32@60 on the kernel command line | 12:26 |
hansfbaier | in uboot? | 12:27 |
stekern | but I think it should default to 640x480-16@60 if you don't specify anything | 12:27 |
stekern | yes in uboot | 12:27 |
stekern | but X get the endian wrong with -16, so you should use -32 | 12:27 |
stekern | you should still be able to see the distorted image with -16 | 12:28 |
hansfbaier | setenv bootargs console=ttyS0,57600 video=ocfb:640x480-32@60 | 12:28 |
stekern | ...and unfortunately it seems like the framebuffer can't keep up properly with -32, so you will experience some flickering... | 12:29 |
stekern | but I have some ideas how to hack around that | 12:29 |
hansfbaier | stekern: still blank :| | 12:30 |
stekern | yes, like that, but if you run the normal boot after that the bootargs will be overwritten | 12:30 |
stekern | look at the mmcboot command | 12:30 |
hansfbaier | mw | 12:31 |
stekern | so copy paste that into an 'fbboot' env var, add the video=.. and then run: run mmcload; run fbboot | 12:31 |
stekern | or something equivalent ;) | 12:31 |
stekern | you can of course just modify the mmcboot command if you find that better | 12:32 |
hansfbaier1 | Enough for today. Many thanks, Stefan. Time for family home evening.... | 12:38 |
hansfbaier1 | Bye. | 12:38 |
poke53282 | stekern: Are there any news about the ABI? | 17:48 |
stekern | poke53282: we had a discussion about it, and the general opinion was being cautious about breaking the ABI and rather try to identify how widespread the problem is and try to notify the projects where it exists | 18:18 |
stekern | I did point out the problems with detecting the problem, and how subtle the bugs are when you hit them | 18:18 |
stekern | Jörn Rennecke had some ideas about adding static code analyses for it in general gcc code, so a warning could be issued for call sites calling vararg functions with a static arg definition, but the conclusion for that was that it's not trivial | 18:22 |
stekern | since the compiler has no knowledge of how the called function actually was defined, there has to be support in the linker for it | 18:23 |
stekern | the discussion was video recorded and I promised to summarize it on the wiki, so we didn't come to a real decision about it | 18:25 |
poke53282 | Is the video available? | 18:38 |
poke53282 | static code analysis in gcc would be the best solution. And put that into -Wall that everyone reckognizes it. But I believe this was discussed a decade ago in gcc mailing list. | 18:40 |
stekern | it's on the way I think, simoncook was our camera man, he'll probably need to split the videos up and upload them to youtube, but I'd expect he'll be working on that in a near future | 18:41 |
stekern | poke53282: really, do you have a link to that discussion? | 18:41 |
poke53282 | No, this is just a guess :) | 18:42 |
stekern | heh, ok, where did the assumption come from? ;) | 18:42 |
poke53282 | But it is an understandable decision. Maybe the opinion would be different if everyone would have worked with the toolchain like I did. | 18:44 |
poke53282 | Well, the assumption comes from the fact that this is not ISO-C standard and the people would like to have this in -Wall. | 18:45 |
stekern | I kind of would have wanted the to go the way with "soft deprecation" of the old ABI and support both, but that of course brings some uglyness to our gcc code | 18:45 |
stekern | ah, fair enough | 18:46 |
poke53282 | But it's a cast and a warning on a cast is something strange. A cast is very often a break of the rules in some way. | 18:46 |
stekern | it doesn't even have to be a cast | 18:47 |
stekern | if the definition is a vararg, but the declaration the caller see is static arg, it's just a normal function call | 18:48 |
poke53282 | At the moment I see also patches in uClibc and eglibc because of this behavior in the ABI. I found this a week ago: https://github.com/blueCommand/or1k-eglibc/commit/bf496f4e1e1dda98f9b8ac3e6f28537e4dc1ed22 | 18:48 |
stekern | ok, but that's "our" code | 18:48 |
stekern | we can't blame others for that ;) | 18:48 |
poke53282 | Yes, but we could get rid of some patches if we change the ABI. That is what I want to say with the link. | 18:49 |
poke53282 | Ok, have to leave for lunch. | 18:50 |
stekern | ah, now I see what that actually does. yeah, that wouldn't be necessary then | 18:51 |
stekern | in the discussion someone made a point about performance regression, but in hindsight I think that was all wrong. using the changed abi would be a performance *win* I think. | 18:54 |
stekern | perhaps not in the convoluted way gcc handles it though | 18:55 |
stekern | since wasn't the registers then copied out to the stack anyways | 18:55 |
stekern | (I do realise you probably already left for lunch, but rely on that you also read the backlogs ;)) | 18:56 |
_franck_ | stekern: how do you choose the pixel clock for the vga_lcd core ? | 19:42 |
poke53282 | stekern: Yes I read the backlogs. All together it is a performance win. But a very tiny one. | 19:52 |
poke53282 | Ok, if your whole program only consists of hundreds of varargs functions with three line of code in each of them then the performance win could be easily 50-80%. ;) | 19:55 |
poke53282 | By the way, the non-splitting of arguments accross registers and stack needs a special handling in libffi. | 19:57 |
poke53282 | Wow, this dejagnu is stuff is harder to cross-compiler then I think. dejagnu needs expect which itself needs Tcl/Tk. And now I see an warning message "Expect can't be cross compiled". What the hell. | 20:20 |
stekern | _franck_: the pixel clock is external to the vga_lcd core | 20:52 |
stekern | i.e. you have to generate it yourself | 20:53 |
stekern | on the sockit I have it hardcoded to 25.2 MHz (640x480@60) | 20:53 |
_franck_ | I know, but I think it is 25MHz for 640x480 @ 60Hz right ? | 20:53 |
_franck_ | ok | 20:54 |
stekern | on the atlys I have a hack where I read out the hlen and vlen and program a pll according to that | 20:57 |
stekern | http://git.openrisc.net/cgit.cgi/stefan/orpsoc/tree/boards/xilinx/atlys/rtl/verilog/dvi_gen/dvi_gen_top.v#n131 | 20:58 |
stekern | just so you don't think I'm crazy, I didn't do that by hand ;) | 20:59 |
_franck_ | :) | 21:00 |
stekern | _franck_: so, did that answer your question? in sockit it's generated in clkgen.v | 21:08 |
_franck_ | yeah, my question was "is it 25MHz for 640x480 ?", so yes it is | 21:12 |
_franck_ | thanks | 21:12 |
-!- knz_ is now known as knz | 21:43 | |
_franck_ | stekern: what do you have just after that http://pastie.org/8385023 ? | 22:08 |
_franck_ | kernel prompt ? | 22:08 |
poke53282 | stekern: If you have a minute look at this: http://pastie.org/8385139 | 22:30 |
poke53282 | the newest config.guess run on or1ksim. | 22:30 |
poke53282 | It does not recognize the build-system. Because it does not know the machine name "openrisc". config.sub seems Ok. | 22:32 |
poke53282 | All the time we were focused on config.sub. But to use configure natively config.guess seems to be important ant not config.sub. | 22:42 |
poke53282 | If there is no objection I can write a mail to <[email protected]> and to the mailing list. | 22:42 |
poke53282 | http://pastie.org/8385181 | 22:48 |
poke53282 | or to this one: http://pastie.org/8385205 | 22:57 |
poke53282 | ok, we are not consistent here because config.sub behaves differently | 22:59 |
poke53282 | Current autoconf: "./config.sub openrisc" -> "or1k-unknown-coff" | 23:11 |
poke53282 | <- *confused* | 23:12 |
poke53282 | hansfbaier, stekern: https://github.com/s-macke/libffi/commits/master | 23:49 |
poke53282 | The starting point | 23:49 |
--- Log closed Tue Oct 08 00:00:30 2013 |
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!