| --- Log opened Mon Sep 30 00:00:18 2013 | ||
| poke53282 | http://s-macke.github.io/jor1k/ | 02:30 |
|---|---|---|
| poke53282 | I have updated the emulator. It uses ext2 hard drive images instead of a ramdisk. And I have added two additional images. gnu c compiler and an X demo. | 02:31 |
| poke53282 | Please, don't use Firefox | 02:31 |
| hansfbaier | poke53282: Can do or1k linux ext2 now? | 02:44 |
| hansfbaier | poke53282: the version I have checked out has the bit ops not implemented yet. | 02:44 |
| poke53282 | Yes, it is possible since a long time. But you have to compile it to support it. Probably ext4, btrfs, ... would work too. | 02:45 |
| poke53282 | Oh, yes | 02:45 |
| poke53282 | You need a tiny patch | 02:45 |
| poke53282 | wait | 02:47 |
| poke53282 | http://www.mail-archive.com/linux@lists.openrisc.net/msg00187.html | 02:47 |
| poke53282 | Add the line "#include <asm-generic/bitops/le.h>" in arch/openrisc/include/asm/bitops.h | 02:48 |
| hansfbaier | poke53282: oh good to know I thought those weren't implemented yet. | 02:50 |
| poke53282 | http://git.openrisc.net/ | 02:50 |
| poke53282 | Here you can find the current development versions of linux | 02:51 |
| poke53282 | But you could also work with the ones from kernel.org. They should be stable and fine. | 02:51 |
| hansfbaier | poke53282: I have jonas' repo, but not head yet. Glad if it runs for now :] | 03:20 |
| stekern | poke53282: tyr-glquake starts | 03:58 |
| stekern | but seems like X doesn't like my keyboard, it says: driver Linux console keyboard wanted to post scancode 46 outside of [0, 0]! | 03:59 |
| poke53282 | So, you can see the level? My emulator stops before | 04:03 |
| -!- Netsplit *.net <-> *.split quits: ams | 04:49 | |
| stekern | poke53282: it starts the "quake console" | 04:56 |
| _franck_ | juliusb: or1k_jtag_adv.c is not part of openocd anymore. Are you sure you're compiling the official version ? | 05:33 |
| stekern | _franck_: well, he asked if the github repo was still usable and you said yes: https://github.com/openrisc/openOCD/blob/master/src/target/or1k_jtag_adv.c | 05:45 |
| stekern | poke53282: ah, appearently you shouldn't use the kdrive mouse and keyboard drivers, but the evdev drivers instead | 06:04 |
| poke53282 | stekern: I know. but at the moment I don't have the keyboard a event driver. I am not sure I should solve it. | 06:06 |
| poke53282 | I need a switch to distinguist terminal and framebuffer | 06:06 |
| poke53282 | ...sure how I should solve it ... | 06:07 |
| stekern | you mean in jor1k? | 06:08 |
| poke53282 | Yes | 06:08 |
| stekern | hmm, don't you get mouse click events somehow? | 06:09 |
| poke53282 | Yes, the mouse is no problem. I emulate a touchscreen device. I could also emulate a keyboard device (which driver do you use?), but then I press in X and in my terminal at the same time a key on the keyboard. | 06:11 |
| poke53282 | or can I transfer the tty input to an event device? | 06:12 |
| stekern | yes, I know. I meant, since you get the mouse event, you could use that as an indicator which of them should be used | 06:12 |
| stekern | don't you have control over the keyboard input at a higher level? | 06:13 |
| stekern | or lower | 06:13 |
| stekern | depending how you see it, I mean can't you capture it in the emulator and direct it either to the uart emulation or some kbd emulation? | 06:14 |
| poke53282 | Yes I have in principle full control. onkeyup, onkeydown | 06:14 |
| poke53282 | Yes, this is the plan. | 06:14 |
| poke53282 | which keyboard driver do you use? | 06:15 |
| stekern | re glquake, it does crash after a while (when the actual demo is about to start) | 06:15 |
| poke53282 | Ok, so you don't see any 3D output. Ok, so we have the same problem. | 06:16 |
| stekern | keyboard driver: "input: AT Raw Set 2 keyboard as /devices/94000000.ocps2/serio0/input/input0" | 06:16 |
| stekern | it crashes because of an unaligned access | 06:17 |
| poke53282 | Yes, the same happens here. | 06:18 |
| poke53282 | I am sure that there are still errors in X. It is unstable. | 06:19 |
| stekern | yes, I managed to crash it by furiously moving around the mouse yesterday | 06:20 |
| poke53282 | I will add more files, especially the fonts to get rid of all these error messages. | 06:20 |
| poke53282 | And I see very often an assert message. | 06:20 |
| poke53282 | So enough things to try. | 06:21 |
| poke53282 | Today I tried also to execute a ./configure && make && make install in the browser. During the configure I got an unaligned access. | 06:23 |
| poke53282 | But I could compile programs with make+gcc successfully that took more then half an hour. | 06:23 |
| poke53282 | E. g. the software Frotz in my emulator. | 06:24 |
| stekern | hmm, I think I've seen something similar, but IIRC it was only on real hw, in or1ksim the ./configure worked | 06:24 |
| stekern | I tried compile a bunch of stuff in or1ksim right after I got the native gcc sorted out, I didn't have any problems then | 06:28 |
| stekern | ah, nice. gcc have finally added tags for their releases in their git mirror | 06:31 |
| poke53282 | http://www.asty.org/cmatrix/ | 06:31 |
| poke53282 | This one I tried today. | 06:31 |
| poke53282 | And configure failed | 06:31 |
| stekern | hmm, ok, I didn't try *that* ;) | 07:55 |
| stekern | I'm in the process syncing gcc btw | 07:56 |
| stekern | I've done the merge and have gave the merged tree to your buildscripts to chunk on | 07:57 |
| stekern | so that should contain the upstream fix for native gcc | 07:58 |
| juliusb | would someone care to pass an eye over this: http://opencores.org/or1k/ORCONF2013_Workshop_ORPSoC_On_DE0_Nano | 08:32 |
| juliusb | or maybe someone playing along at home, if you could give it a go and let me know if any of the tool installations don't work, or if you have any problems you have to work around can you let me know? | 08:32 |
| juliusb | knz: I recall you were eager to participate in the workshop, perhaps you could give it a go if you get a chance? | 08:33 |
| juliusb | _franck_: I'm telling people to clone the openrisc org github openOCD | 08:33 |
| juliusb | _franck_: I notice it's a branch of yours, but it hasn't had any updates for 6 months, so any chance we could perhaps bring the openrisc org one into line with yours? how do we do that? | 08:34 |
| stekern | juliusb: or just tell people to use the upstream version? | 08:36 |
| _franck_ | I was about to tell juliusb the same thing | 08:37 |
| juliusb | haha ok | 08:37 |
| juliusb | what's the git repo for that again?\ | 08:37 |
| juliusb | http://repo.or.cz/w/openocd.git ? | 08:37 |
| olofk | juliusb: I was thinking that we should add icarus to requirements if we want to simulate, but it only supports modelsim, and it might be too much work to run that | 08:37 |
| _franck_ | yes | 08:37 |
| stekern | we can smack a notice on the openrisc/openocd repo that "use this for the deprecated mohor debug if, otherwise use openocd mainline at http://repo.or.cz/w/openocd.git" | 08:38 |
| juliusb | olofk: I wasn't going to worry about simulation of the DE0 nano board itself | 08:38 |
| juliusb | at least, at the workshop | 08:38 |
| juliusb | (openOCD) ok repo link updated | 08:39 |
| juliusb | hmmm | 08:39 |
| _franck_ | olofk: did you add the programing support for orpsoc only in tag 3.1 on purpose ? | 08:39 |
| juliusb | http://pastie.org/8366340 | 08:39 |
| juliusb | _franck_: that repo doesn't work for some reason? | 08:40 |
| _franck_ | I'm using git://repo.or.cz/openocd.git | 08:40 |
| juliusb | yes, strange, not sure why that letter is there | 08:41 |
| juliusb | it works as a URL in my browser but not for git cloning | 08:41 |
| juliusb | (the /w/ one) | 08:41 |
| _franck_ | the is a /r/ one too... | 08:42 |
| _franck_ | s/the/there | 08:42 |
| stekern | note git:// and http:// differences in yours and _franck_'s ursl | 08:42 |
| juliusb | stekern: yes, good point! | 08:42 |
| stekern | but isn't the sf.net repo the official? | 08:42 |
| stekern | git clone git://git.code.sf.net/p/openocd/code openocd-code | 08:42 |
| juliusb | git clone git://repo.or.cz/openocd.git works too | 08:43 |
| stekern | and the or.cz is a mirror | 08:43 |
| juliusb | nice, OK. so that part is now checked :) | 08:44 |
| juliusb | actually, tried building and got: | 08:44 |
| juliusb | http://pastie.org/8366348 | 08:44 |
| _franck_ | stekern: you're right | 08:44 |
| juliusb | I'm guessing it's because I don't have libusb-dev? | 08:45 |
| stekern | sounds very plausible | 08:45 |
| juliusb | mmm I do actually, or according to apt | 08:46 |
| stekern | and I think you have to have both | 08:46 |
| stekern | 1.0 and 2.0 | 08:46 |
| juliusb | I don't see 2.0, just libgusb2 | 08:46 |
| juliusb | described as "GLib wrapper around libusb1" | 08:46 |
| stekern | that's probably plain libusb-dev | 08:47 |
| juliusb | mmm, I already have that too | 08:47 |
| stekern | and libusb-1.0-0-dev is 1.0 | 08:47 |
| stekern | yes, you probably have 2.0, but are missing 1.0 | 08:47 |
| juliusb | ahhhh, I didn't have libusb-1.0-0-dev | 08:47 |
| juliusb | yep that did it | 08:47 |
| juliusb | so you need libusb-dev and libusb-1.0.0-dev | 08:48 |
| juliusb | ?!?!!? | 08:48 |
| stekern | yup | 08:48 |
| juliusb | one for the prereq list... | 08:48 |
| stekern | but I wonder if you are actually building any libusb 1.0 drivers...? | 08:48 |
| stekern | if not, perhaps it'd make more sense to disable it in the config | 08:49 |
| _franck_ | what is your ./configure line ? | 08:49 |
| juliusb | mmm, more ulink errors: http://pastie.org/8366358 | 08:49 |
| juliusb | _franck_: configure line is as per the page (http://opencores.org/or1k/ORCONF2013_Workshop_ORPSoC_On_DE0_Nano#OpenOCD) and is: ./configure --enable-usb_blaster_libftdi --enable-adv_debug_sys --enable-altera_vjtag --enable-maintainer-mode | 08:50 |
| _franck_ | --enable-adv_debug_sys --enable-altera_vjtag are deprecated | 08:50 |
| juliusb | aaah | 08:51 |
| juliusb | that was on the github I think? in the README.md? | 08:51 |
| _franck_ | it works for the github version.... | 08:51 |
| juliusb | ah well now im building from the upstream aren't I? | 08:51 |
| juliusb | so there's a difference in how I configure? | 08:52 |
| juliusb | so how would you say we should configure the upstream version? | 08:52 |
| juliusb | or it's all automatically enabled? | 08:52 |
| _franck_ | ./configure -enable-ftdi --enable-usb_blaster_libftdi --enable-maintainer-mode | 08:52 |
| _franck_ | after that you can choose from the altera vjtag or mohor jtag from the tcl file in tcl/board/or1k_generic.cfg | 08:53 |
| juliusb | cool OK | 08:54 |
| stekern | how can you choose mohor if it's not supported? | 08:54 |
| _franck_ | I mean mohor jtag interface | 08:54 |
| juliusb | TAPs I presume | 08:54 |
| _franck_ | yes TAP | 08:54 |
| stekern | ahh | 08:54 |
| stekern | ok, so support for that still exist? | 08:55 |
| _franck_ | yes, It's needed to work with jtag vpi | 08:55 |
| _franck_ | which is also upstreamed | 08:55 |
| juliusb | cool make works now! | 08:55 |
| juliusb | thanks _franck_ | 08:55 |
| juliusb | instructions on that page should be good now, just maybe need to mention the prereqs | 08:56 |
| stekern | but doesn't adv debug sys have an own tap core as well? | 08:56 |
| _franck_ | I'm using the core from opencores. I think there is another one in adv_debug_sys | 08:57 |
| stekern | umm, adv_debug_sys is also from opencores, can you be a bit more precise ;) | 08:57 |
| _franck_ | ok wait :) | 08:57 |
| stekern | I thought we were only using adv_debug_sys now in openocd | 08:58 |
| _franck_ | https://github.com/openrisc/orpsoc-cores/blob/master/cores/jtag_tap/jtag_tap.core | 08:58 |
| _franck_ | this jtag tap | 08:58 |
| _franck_ | and this debug interface: https://github.com/openrisc/orpsoc-cores/blob/master/cores/adv_debug_sys/adv_debug_sys.core | 08:59 |
| olofk | juliusb: What did you mean with adding programming support in tag 3.1? Did I mess up something git-wise? | 08:59 |
| _franck_ | olofk: https://github.com/openrisc/orpsoc/commits/master , I can't see the patch here | 09:00 |
| stekern | you at least mess up what person you're direcing your questions to | 09:00 |
| stekern | ;) | 09:00 |
| _franck_ | olofk: however, I can see it here: https://github.com/openrisc/orpsoc/commits/3.1 | 09:00 |
| olofk | Sorry _franck_ | 09:00 |
| olofk | Stupid fucking crap VCS | 09:01 |
| _franck_ | stekern: this is what we do not support in openocd: https://github.com/openrisc/orpsoc-cores/blob/master/cores/dbg/dbg.core | 09:01 |
| stekern | nah, I think it's github that's fucking crap | 09:01 |
| stekern | it sometimes doesn't update | 09:01 |
| stekern | the web interface that is, try pulling master and see if the patch is there | 09:02 |
| stekern | _franck_: thanks, I understand now | 09:02 |
| _franck_ | the best thing would be to clone the offical openocd repo into openrisc github and add dbg_if support here | 09:03 |
| _franck_ | i could do that | 09:03 |
| stekern | ok, no, master branch doesn't have those commits... | 09:04 |
| stekern | how did you manage that olofk? | 09:04 |
| _franck_ | everything is possible with git ;) | 09:05 |
| stekern | yeah, but I can't come up how to do that from the top of my head | 09:05 |
| stekern | ...which means... olofk must now be a git master! *bows* | 09:06 |
| _franck_ | :) | 09:06 |
| juliusb | we can live without orpsoc handling the board programming for the workshop, it's a simple enough command | 09:36 |
| stekern | humm... search for 'or1k' on this page: https://sourceware.org/cgi-bin/cvsweb.cgi/src/config.guess?rev=1.63&content-type=text/x-cvsweb-markup&cvsroot=src | 09:37 |
| stekern | how have that got there? | 09:37 |
| olofk | ok... so what the hell should I do to solve this mess? orpsoc's revision tree is starting to look like a jungle | 09:48 |
| powermaniac | Hey | 10:17 |
| powermaniac | I was wondering if anyone in here might know how to make a .bootimg? | 10:17 |
| powermaniac | And .img from an iso? | 10:18 |
| powermaniac | Trying to get Debian onto my Nexus 7 to test out | 10:18 |
| stekern | olofk: so how did you get the tagged release out there without pushing master? | 10:30 |
| olofk | stekern: Not sure, but I think I did git push --tags | 10:30 |
| olofk | Maybe that _only_ pushed the commit with the tag | 10:30 |
| stekern | ah! | 10:31 |
| stekern | so... just 'git push origin master' now then | 10:31 |
| stekern | I didn't know you actually could push *just* the tags | 10:31 |
| knz | hi guys | 10:31 |
| powermaniac | Howdy | 10:32 |
| knz | stekern: do you happen to know where I can find the pin mappings for your orpsoc archive from last year? | 10:32 |
| knz | for the uart | 10:32 |
| knz | it's at the bottom but I can't remember which pins | 10:32 |
| knz | never mind found it | 10:41 |
| knz | yes! | 11:14 |
| knz | stekern: it boots :) | 11:14 |
| knz | however: | 11:14 |
| knz | SF: Unsupported manufacturer 01 | 11:14 |
| knz | Failed to initialize SPI flash at 0:0 | 11:14 |
| knz | No SPI flash selected. Please run `sf probe' | 11:14 |
| knz | I thought it would boot off the on-board flash | 11:16 |
| LoneTech | SPI flashes have a few different protocols, so you need to enable the appropriate CONFIG_SPI_FLASH_ATMEL or similar | 11:17 |
| knz | well | 11:18 |
| LoneTech | 01 would be CONFIG_SPI_FLASH_SPANSION I think | 11:18 |
| knz | I thought this orpsoc image was already ustomized for the nano | 11:18 |
| LoneTech | but that message is u-boot, not orpsoc itself? | 11:18 |
| knz | correct | 11:19 |
| LoneTech | so the boot rom worked | 11:19 |
| LoneTech | the difference could well be that DE0 nanos could come populated with different EEPROMs | 11:20 |
| knz | grmbl | 11:21 |
| knz | not sure what to do now :) | 11:22 |
| stekern | knz, what is it that you have in there now? | 11:22 |
| knz | stekern: http://opencores.org/or1k/FPGA_Development_Boards#Pre-built_image_with_orpsoc.2C_U-Boot_and_Linux | 11:22 |
| knz | this one | 11:22 |
| stekern | ok | 11:22 |
| stekern | could be a bug in orpsoc | 11:23 |
| stekern | if you does it happen all the time? | 11:23 |
| stekern | -if | 11:23 |
| knz | yes | 11:23 |
| LoneTech | you could build a u-boot that likes the spi flash, boot it over serial, and use it to write it to flash, in principle | 11:23 |
| stekern | -you | 11:23 |
| knz | it does happen all the time | 11:24 |
| LoneTech | hm, de0-nano manual seems to indicate it has Altera's EPCS | 11:25 |
| knz | of course I will be bringing this equipment next weekend at orconf | 11:25 |
| stekern | LoneTech: yes, it should be an EPCS there | 11:25 |
| knz | anything I should look at myself to investigate? | 11:26 |
| stekern | you could try building a newer orpsoc ;) | 11:26 |
| stekern | there's at least a bug in the arbiter that I *think* caused issues like that | 11:26 |
| knz | yeah I think I will wait a few days then :) | 11:27 |
| knz | but I am very glad my serial adapter now works | 11:27 |
| stekern | but SPANSION part sounds odd though | 11:27 |
| knz | I didn't say spansion | 11:27 |
| stekern | I know | 11:27 |
| knz | should I acquire an additional sd card with spi adapter ? | 11:28 |
| stekern | I don't know, do you need one? | 11:29 |
| knz | well | 11:29 |
| knz | no :) | 11:29 |
| knz | but if it makes troubleshooting / booting easier in the future, I may be interested | 11:29 |
| stekern | so don't ;) | 11:29 |
| knz | it's more a matter of being well prepared :) | 11:30 |
| stekern | easiest way to boot the de0 nano board is by loading the program into memory with gdb | 11:30 |
| knz | ok | 11:31 |
| LoneTech | per the epcs datasheet the epcs64 simply does not support read id, so the probe value is likely bogus | 11:31 |
| LoneTech | (possibly it's a relabeled spansion device and altera didn't inform us) | 11:32 |
| stekern | perhaps | 11:32 |
| knz | so the next steps are build an updated orpsoc | 11:32 |
| stekern | this is the define in config: CONFIG_SPI_FLASH_STMICRO | 11:33 |
| knz | and if that does not work try to change the SPI id | 11:33 |
| LoneTech | the commands and organisation match up with Spansion S25FL064A | 11:38 |
| LoneTech | so except for Altera's notice that it does not support read ID, on which it seems to have replied Spansion, it looks like a Spansion chip | 11:39 |
| LoneTech | pinout matches too, except altera specify to hardwire HOLD# and W# high, meanning not paused or write protected | 11:42 |
| LoneTech | (which incidentally explains the funny number of VCC pins) | 11:43 |
| LoneTech | ST Micro's M25P64 is similar too, but has id 20 13, where the spansion part has 01 0216 | 11:47 |
| stekern | so... it could be possible that old epcs64 was actually ST Micro's M25P64 (or at least responded as such) and new ones Spansion S25FL064A? | 11:53 |
| LoneTech | the "electronic signature" of s25fl064a is 16, which also is the capacity code; that's the number altera specify as EPCS device silicon ID | 11:53 |
| LoneTech | it appears quite likely | 11:54 |
| LoneTech | they took the common SPI flash design, said not to use hold or write protect or manufacturer id, but only use capacity to identify it | 11:54 |
| LoneTech | but they do admit to the read device ID opcode on the EPCS128, so that one is probably ordered with an altera ID | 11:55 |
| LoneTech | erm. actually they say one should read only one byte, which should be 18h.. which is the manufacturer ID byte | 11:57 |
| LoneTech | now where did I have the mfg id table? | 11:58 |
| LoneTech | don't see that code in JEDEC 106AF | 12:00 |
| LoneTech | per that spec it's an unassignable number, wrong parity | 12:06 |
| LoneTech | but that may be the wrong spec for this value | 12:06 |
| LoneTech | ah, spansion was founded by AMD+Fujitsu and fully controlled by AMD for a while; explains their use of the AMD mfg id | 12:10 |
| LoneTech | so per Altera's spec, one should not probe EPCS devices as other SPI flashes, but per your results they are in fact rebranded chips from multiple brands | 12:12 |
| LoneTech | hang on, I've been misreading | 12:13 |
| LoneTech | they tell you to *skip* the manufacturer ID and high 8 bits of device id, leaving only the capacity byte. they changed their datasheet probably because larger chips were missing the electronic signature command | 12:14 |
| LoneTech | so the very data u-boot is probing by is the "dummy bytes" in figure 14 of the Jan-2012 EPCS datasheet | 12:15 |
| LoneTech | everything points to EPCS devices always being standard SPI flashes from arbitrary manufacturers, relabeled | 12:16 |
| LoneTech | and U-Boot has never had support for the mythical EPCS dies, with their quirk of being indistinguishable from the various common flashes | 12:19 |
| LoneTech | so Altera switched out the chip in EPCS64 devices used on various DE0 Nano boards, which was all right by their datasheet since it said to never mind the manufacturer code | 12:20 |
| stekern | nice digging LoneTech! | 12:21 |
| stekern | I was fooled by the error message, since similar have appeared due to that arbiter bug | 12:22 |
| knz | ok | 12:22 |
| LoneTech | basically an EPCS64 will be just some 128*256*256*8 SPI flash | 12:22 |
| knz | now what's next? | 12:23 |
| LoneTech | build a u-boot with support for your relabeled Spansion chip :) | 12:23 |
| stekern | yup | 12:23 |
| LoneTech | the orpsoc is running fine, the bootloader software just didn't recognize the spi flash part | 12:24 |
| knz | can I upload an updated uboot without reflashing? | 12:24 |
| LoneTech | (mostly conjecture, but I think it looks likely) | 12:24 |
| LoneTech | yes, you should be able to load it either into u-boot using ymodem or similar or via jtag using a debugger | 12:25 |
| LoneTech | I'm not familiar with u-boot->u-boot starting myself though | 12:25 |
| knz | k | 12:26 |
| stekern | I can't remember the commands, but yes, you load u-boot into some place in memory and then just write it to the right address in flash | 12:26 |
| LoneTech | thing is, the write into flash command won't work until u-boot recognizes the flash | 12:27 |
| stekern | haha! | 12:27 |
| stekern | right... | 12:27 |
| stekern | I was a bit to fast there | 12:27 |
| stekern | so, no, no other option than flashing | 12:28 |
| LoneTech | well, there are options, they're just trickier | 12:28 |
| LoneTech | you could even use u-boot to modify u-boot in RAM to make it think the Spansion part is an ST ;) | 12:28 |
| stekern | if he loads the other u-boot via gdb | 12:28 |
| stekern | he's fine too | 12:29 |
| LoneTech | yes | 12:29 |
| olofk | I'm just waiting for _franck_ to scream that you should use barebox instead ;) | 13:25 |
| LoneTech | that may well be a good idea | 13:26 |
| LoneTech | it uses the same m25p80.c driver for all of these chips, per the still unidentified JEDEC standard | 13:31 |
| LoneTech | (I've dug through JEDEC's lists of memory related standards, and mailed and asked them, and they don't seem to know of the spec for SPI flash memory that vendors adhere to) | 13:32 |
| _franck_ | barebox should be the default openrisc linux bootloader :) | 13:43 |
| knz | tbh I'm fine with either | 14:05 |
| knz | at the end of the day I'm looking forward to presenting a running platform to my students | 14:05 |
| knz | how it boots is of little concern to me | 14:05 |
| LoneTech | huh. Atmel filed a patent for the identification command in 2003. | 14:37 |
| knz | this is crazy | 14:38 |
| LoneTech | apparently it's for appending a Pascal-style string of "extended information" | 14:45 |
| LoneTech | also, Spansion documented that the common flash interface doesn't cover SPI | 14:48 |
| stekern | hmm syncing or1k-src became messier than I'd thought | 14:49 |
| stekern | so, obviously, peter have took cvs snapshots and then rebased upon that. at least in the beginning, then in the middle he did a merge and never pushed that cvs snapshot to "upstream-cvs" | 14:50 |
| stekern | I tried to do a cvs snapshot in to upstream-cvs and rebase upon that, but it of course went crazy when it arrived to the cvs merge in the middle of or1k branch | 14:52 |
| stekern | took a while before I understood what was going on | 14:52 |
| stekern | so, plan now is to cherry-pick that cvs snapshot into upstream-cvs and rebase upon that | 14:52 |
| stekern | does that make sense? | 14:52 |
| LoneTech | I think so, but I'm not sure I understand the situtation. Also, I should leave the office and get some rather late lunch. | 14:58 |
| stekern | jeremybennett: it doesn't seem like embecosm's sourceware git tree is syncing against upstream anymore | 18:21 |
| jeremybennett | jeremybennett: Ah - OK. I'll get simoncook to take a look when he is back from vacation tomorrow. | 18:23 |
| stekern | ok, no hurry. I considered using that instead of continuing on the path with cvs snapshot dumps we currently have in or1k-src | 18:26 |
| stekern | but I went on with another cvs checkout, so it can wait until next time | 18:26 |
| rfajardo | Is it the best idea to use orpbuild to install the toolchain? | 18:38 |
| rfajardo | why are there so many things under github if git.openrisc.net is also available? | 18:39 |
| knz | rfajardo: it's a mirror | 18:51 |
| knz | so people can use all the nice graphical stuff of github | 18:51 |
| stekern | naah | 18:52 |
| rfajardo | I have the feeling that github has been more used lately | 18:59 |
| stekern | yes | 19:00 |
| stekern | it seemed like what most people tended to use, so we created the organization as a common ground | 19:02 |
| rfajardo | nice, I will try to build up my tools | 19:07 |
| juliusb | _franck_: when building the OpenOCD from upstream it doesn't work the same as from your lovely repo. first is that the altera-dev.tcl isn't there. but if I copy it in I get this: http://pastie.org/8367869 (openOCD as installed via these instructions which we worked out this morning: http://opencores.org/or1k/ORCONF2013_Workshop_ORPSoC_On_DE0_Nano#OpenOCD ) | 20:13 |
| _franck_ | juliusb: ./src/openocd -f ./tcl/interface/altera-usb-blaster.cfg -f ./tcl/board/or1k_generic.cfg | 20:16 |
| juliusb | .... almost :) | 20:17 |
| juliusb | Runtime Error: embedded:startup.tcl:47: Can't find target/or1k.cfg | 20:17 |
| _franck_ | did you make install openocd ? | 20:17 |
| juliusb | no | 20:17 |
| juliusb | it's required? | 20:17 |
| _franck_ | no but it needs a small hack | 20:18 |
| juliusb | cool, whereabouts? | 20:18 |
| _franck_ | add ./tcl/ in from of target/or1k.cfg in ./tcl/board/or1k_generic.cfg | 20:19 |
| _franck_ | s/from/front | 20:19 |
| juliusb | or I can just add "-s ./tcl" on the command line | 20:19 |
| juliusb | ... it seems | 20:19 |
| juliusb | awesome! | 20:19 |
| juliusb | Chip is or1200.cpu, Endian: big, type: or1k | 20:20 |
| juliusb | Target ready... | 20:20 |
| juliusb | it's a pretty colour! | 20:20 |
| _franck_ | :) | 20:20 |
| _franck_ | if you had installed it that would be openocd -f interface/altera-usb-blaster.cfg -f board/or1k_generic.cfg | 20:21 |
| _franck_ | without any hack | 20:21 |
| _franck_ | but -s ./tcl is okay, I didn't know that | 20:21 |
| juliusb | ok cool. will note that | 20:21 |
| juliusb | so how were you doing your fancy bits of downloading code and setting the PC without GDB? | 20:21 |
| _franck_ | telnet 127.0.0.1 4444 | 20:22 |
| juliusb | ooooh | 20:22 |
| _franck_ | then load_image /full/path/or/it_doesnt/work | 20:22 |
| _franck_ | reg npc 0x100 | 20:22 |
| _franck_ | resume | 20:22 |
| _franck_ | if your elf has no program header it won't load (like my small led_blink) | 20:24 |
| _franck_ | http://openocd.zylin.com/#/c/1671/ should fix it | 20:24 |
| _franck_ | however, it was waorking yesterday but it doesn't work tonight ;) | 20:25 |
| _franck_ | I'm working on it | 20:25 |
| _franck_ | juliusb: did you change your FPGA JTAG ID in or1k_generic.cfg ? | 20:28 |
| _franck_ | I'm sure you did | 20:29 |
| juliusb | noope | 20:29 |
| juliusb | works fine | 20:29 |
| juliusb | im running with adv_debug_sys though I think | 20:29 |
| _franck_ | don't you have an error/warning about not matching jtag idcode ? | 20:30 |
| juliusb | haha oh yes some big warnings | 20:30 |
| _franck_ | :) | 20:30 |
| stekern | where does that come from? the FPGA JTAG ID I mean? | 20:30 |
| _franck_ | the FPGA JTAG TAP | 20:31 |
| _franck_ | the real one | 20:31 |
| juliusb | stekern: I'm having problems with my toolchain I compiled :( | 20:37 |
| juliusb | http://pastie.org/8367930 | 20:37 |
| juliusb | where are those usually? | 20:37 |
| juliusb | http://pastie.org/8367936 | 20:38 |
| olof | ok, I think I fixed the missing orpsoc commits now | 20:40 |
| juliusb | hey olof | 20:45 |
| juliusb | i have a patch for you too, at some stage | 20:45 |
| juliusb | allows you to have fancy things like ~ and $HOME in your cores_root and system_root variables :) | 20:46 |
| stekern | juliusb: when did you pull or1k-src last? | 20:47 |
| olof | juliusb: Great. I thought that os.abspath used os.expanduser for ~, but it looks like I was wrong | 20:47 |
| juliusb | stekern: yesterday before I built | 20:47 |
| juliusb | ohhh now that I look I notice I've done some work on this | 20:48 |
| juliusb | and it wasn't quite in the latest state | 20:48 |
| * juliusb slaps his forehead | 20:48 | |
| olof | stekern, _franck_ : Is the uart patch in the pull request tested now? There was some discussions about an alternative patch IIRC | 20:49 |
| _franck_ | yes it is. | 20:49 |
| olof | _franck_: Great. Then I'll add it | 20:50 |
| stekern | I've been testing that on sockit as well, so it should be fine | 20:50 |
| * juliusb feels a tool chain recompile coming on... | 20:50 | |
| olof | Now something is messed up with orpsoc-cores | 20:54 |
| olof | # On branch master | 20:56 |
| olof | # Your branch and 'origin/master' have diverged, | 20:56 |
| olof | # and have 1 and 5 different commits each, respectively. | 20:56 |
| olof | # (use "git pull" to merge the remote branch into yours) | 20:56 |
| olof | No fucking way that I will do a git pull. That will probably mess it up even more | 20:57 |
| juliusb | hmmm, I don't understand git well enough to help you here... | 21:01 |
| olof | And why can't git remember my passphrase? | 21:02 |
| _franck_ | I can feel how much you love git ;) | 21:02 |
| stekern | didn't you just push to origin/master? | 21:05 |
| olof | stekern: That was orpsoc | 21:05 |
| stekern | ah, right | 21:05 |
| olof | Ok, so I think that my local copy and the one on github is in sync now | 21:06 |
| olof | Now I want to add _franck_'s patch for the uart. Why does it insist on merging? Can't it just apply the damn patch on top of my tree? | 21:06 |
| stekern | I have "bricked" my sockit now... | 21:06 |
| olof | stekern: Oh... what did you do? | 21:07 |
| stekern | I made a bad arm kernel that doesn't boot, and then I wanted to remove the bootdelay in u-boot, so I set it to 0 | 21:07 |
| stekern | appearently that really meant 0 bootdelay | 21:08 |
| stekern | so now it just boots my bad kernel | 21:08 |
| olof | Ahh... I've done the same thing on desktop machines :/ | 21:08 |
| stekern | luckily everything is on a sdcard | 21:08 |
| stekern | but I'm not sure how to alter the u-boot environment from linux, except by wiping it completely | 21:09 |
| stekern | ...which I don't want | 21:09 |
| olof | You should have used barebox | 21:09 |
| _franck_ | yeah, in barebox you have a "sockit restore everything" command :) | 21:12 |
| _franck_ | I'm telling you barebox is really great ! | 21:12 |
| olof | orpsocv3 runs fine in barebox too | 21:12 |
| olof | And I'm using sockit restore everything all the time | 21:13 |
| stekern | fantastic | 21:16 |
| olof | u-boot stores the env on some hardcoded memory address, doesn't it? | 21:23 |
| stekern | yes, but I don't know the address | 21:32 |
| stekern | I can find out though | 21:32 |
| stekern | and there are linux tools to read/write the environment | 21:32 |
| olof | How do you read out the data if you know the address? Is that where dd comes in? | 21:33 |
| stekern | this wasn't what I was about to do this evening though... | 21:33 |
| stekern | no, there are fw_printenv/fw_saveenv utils | 21:33 |
| stekern | bah... those can only read MTD devices | 21:34 |
| juliusb | _franck_: what should the right TAP ID be, then, for the DE0 nano build? | 21:36 |
| juliusb | oh I see it's found 0x020f30dd but expected 0x020b30dd | 21:38 |
| juliusb | so I changed the value in tcl/board/or1k_generic.cfg and it doesn't appear to complain anymore! :) | 21:39 |
| juliusb | ummm, I downloaded an image and it reckons it went at like 350kB/s?? | 21:40 |
| juliusb | (via openOCD) | 21:40 |
| juliusb | does it really go that fast? | 21:40 |
| juliusb | omg it looks like it! I verified the image and it reckons its ok | 21:41 |
| juliusb | what defines the memory map of cores in orpsocv3? | 21:55 |
| juliusb | looks like the generated wb_intercon gets some addresses... but where do they come from? do cores have their address specified with them now? | 21:57 |
| juliusb | and stekern, _franck_ , how have you been compiling software to run on orpsocv3 builds? like which library have you been using? which drivers etc? it was all included in orpsocv2 but I don't see it in orpsocv3 yet | 21:57 |
| juliusb | ahhh | 21:58 |
| * juliusb has found de0_nano/data/wb_intercon.conf | 21:58 | |
| stekern | juliusb: yes, there is the mem map | 22:04 |
| stekern | sometimes the simplest solutions are the best... just renaming the linux image on the sdcard makes u-boot boot fail => I get access to it | 22:05 |
| stekern | juliusb: what do you need drivers for? | 22:07 |
| stekern | I have just used normal newlib | 22:07 |
| juliusb | ok, and drivers? just orpsoc-ish ones? | 22:08 |
| juliusb | orpsoc(v2)-ish ones? | 22:08 |
| stekern | yeah, what drivers? | 22:08 |
| juliusb | UART? | 22:09 |
| stekern | in newlib? | 22:09 |
| juliusb | no, just in general | 22:09 |
| stekern | or libgloss | 22:09 |
| juliusb | dunno, there aren't any AFAIK? | 22:09 |
| stekern | I meant, isn't the uart driver in newlib good enough? | 22:09 |
| juliusb | oh tehre is one? | 22:09 |
| * juliusb looks | 22:09 | |
| stekern | well, "driver" | 22:10 |
| juliusb | oh yes there is on there! | 22:10 |
| stekern | you should know best, you did the stuff there! ;) | 22:10 |
| juliusb | oh you're right. I recall now. Yes we define the base address and other parameters in the board's .S file | 22:11 |
| stekern | and AFAIR, the motivation was to get rid of all the drivers in orpsocv2 | 22:11 |
| juliusb | it's been a while :0( | 22:11 |
| juliusb | totally | 22:11 |
| stekern | I'm confused... the only thing I did to break the ARM kernel was to change a bit of formatting in ocfb | 22:14 |
| stekern | no, I removed an init of a global variable too | 22:16 |
| stekern | but... that's implied that globals are 0, no? | 22:17 |
| stekern | this is odd | 22:19 |
| juliusb | stekern: are globals really all assumed to be zero? | 22:20 |
| juliusb | (if uninitialised) | 22:21 |
| stekern | if you are following the C standard, yes | 22:22 |
| juliusb | oh right, fair enough! :) | 22:23 |
| stekern | but I assume that gcc does that | 22:23 |
| stekern | I think you can't make that assumption in microsofts compiler, but I don't think I'm using that to compile this ARM kernel.. | 22:24 |
| stekern | not sure at this time of the day though | 22:24 |
| juliusb | haha | 22:24 |
| juliusb | yes it's after midnight in your part of the world. have you given up sleeping lately? | 22:24 |
| stekern | I just want to figure out the right(tm) way to get the endian right to/from the framebuffer mem | 22:25 |
| stekern | at the same time I'm syncing or1k-src from upstream and a lot is broke now... | 22:26 |
| stekern | I thought I'd push something broken onto there just the days before the workshop, doesn't that sound like a good idea? | 22:27 |
| juliusb | :) | 22:27 |
| juliusb | we have some precompiled stuff now | 22:27 |
| juliusb | my precompiled one works now | 22:27 |
| stekern | ah, right, so no worries | 22:27 |
| stekern | the gcc sync went smooth at least, no problems so far | 22:28 |
| stekern | aha! I found another change... so it wasn't the init of the global | 22:35 |
| stekern | juliusb: so do you get any sign of life from the de0 nano? | 23:06 |
| juliusb | yep! | 23:46 |
| juliusb | it's alive now | 23:46 |
| juliusb | just wondering about the best way to hook up this embecosm UART board | 23:46 |
| juliusb | it needs a ground and VCC | 23:46 |
| juliusb | just worried the VCC might pull more current than the FPGA pad can supply, although it worked fine at the chiphack event | 23:46 |
| juliusb | anyway, the UART pins need to be changed on the de0 nano board for the demo, and a pin needs to be added and set to '1' to supply the VCC, not sure of the best way to achieve that | 23:47 |
| juliusb | (logistically, I mean should I just apply a patch or can I check this stuff in?) | 23:47 |
| juliusb | _franck_: one thing I've noticed is that if I reset the board with the pushbutton while openocd is attached it kinda freaks out and can't reattach, or at least I can't find a command which makes it do that - any suggestions? | 23:48 |
| juliusb | halt just freaks out | 23:48 |
| juliusb | I presume because the TAP has all been reset | 23:48 |
| --- Log closed Tue Oct 01 00:00:20 2013 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!