| --- Log opened Thu Feb 12 00:00:37 2015 | ||
| stekern | blueCmd: was the offer for a git janitor perhaps? ;) | 00:07 |
|---|---|---|
| stekern | ah, ah git clone of or1k-gcc had time to finish at 40k/s during the night... | 00:07 |
| stekern | olofk: it should be in here: https://github.com/skristiansson/orpsoc-cores/tree/eco32 | 00:09 |
| stekern | olofk: I just built a microblaze-elf (in paralell with an or1k-elf) toolchain according to the updated instructions on opencores.org | 02:26 |
| stekern | (iow, they seem to be solid) | 02:37 |
| -!- Netsplit *.net <-> *.split quits: antgreen, rhythmx, FreezingCold | 02:52 | |
| -!- Netsplit over, joins: FreezingCold | 02:59 | |
| wallento | the musl-cross tool does not provide the option to build from the git repositories, correct? | 07:53 |
| olofk | stekern: Hey! There should be a clause that you can't use the build instructions for evil :) | 08:02 |
| olofk | wallento: I think you can override some stuff. Did you look at stekern's clone of musl_cross? | 08:03 |
| olofk | And I saw that the newlib patches were applied btw | 08:03 |
| wallento | no, I will have a look at it | 08:05 |
| olofk | I think that it only supports cloning musl from git. | 08:11 |
| olofk | But it gets an archive from github for gcc if that helps | 08:11 |
| wallento | ah, okay | 08:11 |
| wallento | thats the trick | 08:11 |
| wallento | do I understand it correctly, that musl support is not upstream in gcc? | 08:13 |
| wallento | mmh, I will manually trigger builds for the moment :) | 08:18 |
| olofk | I don't know if gcc requires some patches to work with musl. Never considered that there would be any interaction between those | 09:06 |
| wallento | I just followed the instructions so far and made it only for releases. is there any active work on musl at the moment, by the way? | 09:08 |
| wallento | okay, works: http://lis.ei.tum.de/pub-download/openrisc-builds/or1k-linux-musl/ | 09:20 |
| wallento | nice filenames: or1k-linux-musl_1.1.6-bintuils_2.25-gcc_4.9.1-linux_3.15-ubuntu-14.04-amd64.tgz | 09:20 |
| wallento | :-D | 09:20 |
| wallento | the musl build does not do multilib builds? | 09:22 |
| olofk | awesome | 09:34 |
| stekern | olofk: it's actually for a good cause, I'm porting a little kernel to or1k, and there's a microblaze port to copy off | 10:11 |
| stekern | so I wanted to know that it at last compiles and boots | 10:11 |
| stekern | s/a little kernel/little kernel | 10:11 |
| stekern | https://github.com/travisg/lk/ | 10:12 |
| blueCmd | stekern: no, it was for DevOps for a high-frequency trading thingy | 10:32 |
| stekern | ah, oki | 10:39 |
| olofk | stekern: Cool. Still waiting for the Windows CE port though | 10:49 |
| olofk | antgreen`: https://github.com/olofk/moxie-cores | 10:50 |
| olofk | I couldn't figure out what should go in the init-valid file for the icache, so I just initialized it to all zeroes | 10:51 |
| juliusb | the moxie stuff looks fun - what infrastructure exists for in way of debugger, etc? | 11:22 |
| antgreen` | I have firmware with a tiny gdb stub in it | 11:23 |
| -!- antgreen` is now known as antgreen | 11:23 | |
| antgreen | http://moxielogic.org/blog/a-really-tiny-gdb-remote-protocol-stub.html | 11:24 |
| antgreen | but no jtag debugging . I'm not sure how that works yet. | 11:24 |
| stekern | olofk: joking aside, windows ce is one of the least crappy things that has came out of that company. especially in the incarnation of win mobile 6.1 | 11:25 |
| juliusb | OK cool. But no hardware debugging? | 11:25 |
| antgreen | that's right | 11:26 |
| antgreen | once I tried to implement the gdb remote protocol in hardware... https://github.com/atgreen/moxie-cores/tree/master/cores/gdbtarget . It's not complete. Someday I may finish it. | 11:27 |
| juliusb | Cool. It looks like an ISA that'll result in very compact implementations. | 11:27 |
| juliusb | Got a LUTs/LEs number for FPGA implementation? | 11:27 |
| antgreen | not handy. I'd generate some now, but I'm under pressure to get something else done for work right now! | 11:28 |
| juliusb | Yeah I saw someone who did that for the RISC-V I think, literally accepted the RSP characters over UART and did all of the processing in hardware IIRC. Quite neat :) | 11:28 |
| juliusb | no problems, just curious | 11:29 |
| antgreen | oh, really? pointers? | 11:29 |
| juliusb | just looking... | 11:29 |
| antgreen | oh ,man, that was my idea! Too bad they beat me to it. | 11:30 |
| juliusb | Page 5 of http://riscv.org/workshop-jan2015/riscv-bluespec-workshop-jan2015.pdf | 11:30 |
| juliusb | To be honest I'm not sure if it's exactly what I said it was now, at least it doesn't look like it on that slide, but I'm pretty sure that's what they claimed to have done. | 11:31 |
| juliusb | The other bad news is that it looks like if it exists, it'd be in Bluespec :( | 11:31 |
| antgreen | it loos like exactly what I did. a | 11:33 |
| antgreen | 'gdb stub' in hardware that hooks directly into the CPU | 11:34 |
| olofk | Hmm.. would it make sense/be possible to implement the or1k debug protocol in Moxie? Then we could reuse adv_debug_sys and OpenOCD and things directly | 11:36 |
| olofk | stekern: I feel sorry for WindowsCE sometimes. It's mostly used as a joke | 11:37 |
| juliusb | olofk: the advanced debug sys stuff (and even the original one) is independent of the processor it's attached to I reckon. | 11:40 |
| antgreen | where can I read about all of that? | 11:41 |
| juliusb | So you could attach it to anything and write the appropriate bit of OpenOCD to translate GDB's "read my PC" into the appropriate register read on the CPU and you're about done | 11:41 |
| juliusb | antgreen: andvanced debug sys? | 11:41 |
| antgreen | yes | 11:42 |
| juliusb | http://opencores.org/project,adv_debug_sys | 11:42 |
| olofk | juliusb: Yeah, that was what I was hoping for. Just a set of instructions, like read pc, stall CPU, reset and stuff | 11:42 |
| olofk | antgreen: Does mox125 work btw? I never got it to move the PC. Looked like icache is the culprit, never reporting valid to the CPU | 11:44 |
| antgreen | olofk: no! you caught me in the middle of adding the new icache | 11:44 |
| antgreen | I'll have it working again in a couple of days | 11:44 |
| antgreen | although it should report valid to the CPU. Just give me a little more time... | 11:45 |
| juliusb | olofk: sure, I'm not so familiar with the adv_debug_sys but it is very similar to the original one. Basically you select the "slave" (ie cpu0, cpu1, or wishbone bus) in a config register, load in the address and whether it's a read or write, press go, and then poll another bit, wait until it looks like the access has completed, and if it's a read, shift out the read data, otherwise move along | 11:45 |
| olofk | antgreen: Yeah. I probably chose a bad time to play around with Moxie. No stress. Just let me know if you want some help testing stuff | 11:46 |
| olofk | juliusb: Makes sense. I've never looked at the details, so it's a bit of a black box for me | 11:47 |
| olofk | juliusb: You had a good time on the prison island btw? | 11:49 |
| wallento | okay, there we are: http://lis.ei.tum.de/pub-download/openrisc-builds/or1k-linux-musl/ | 12:14 |
| juliusb | olofk: always :) | 12:26 |
| juliusb | ironically I consider visiting the ex-British prisoner colony as a brief release from the confines of the UK | 12:27 |
| stekern | cool, lk boots now | 14:57 |
| stekern | http://pastie.org/9942073 | 14:57 |
| ysionneau | what's lk ? | 15:00 |
| olofk | stekern: Nice. How big is the binary? | 15:01 |
| stekern | mm, wait | 15:02 |
| stekern | 84k | 15:03 |
| stekern | ysionneau: https://github.com/travisg/lk/ | 15:04 |
| ysionneau | thx | 15:04 |
| ysionneau | ah some embedded kernel | 15:05 |
| ysionneau | is the application (payload) linked with the kernel? | 15:05 |
| ysionneau | or is this loading the application via ethernet/serial ? | 15:05 |
| stekern | I think it's used as a bootloader on some android systems | 15:05 |
| stekern | no, the applications are linked in (afaict) | 15:06 |
| ysionneau | ok, like RTEMS then | 15:06 |
| stekern | I just started to look at it today ;) | 15:06 |
| ysionneau | interesting | 15:06 |
| ysionneau | and it already works? :p | 15:06 |
| ysionneau | that's productivity! | 15:06 |
| stekern | well, it boots... I don't evn have the timer running ;) | 15:06 |
| ysionneau | cool anyway! | 15:07 |
| stekern | bedtime here now, will try to sleep with the *very* loud thai karaoke garden party going on down-stairs... | 15:09 |
| wallento | rtems toolchain also builds automatically now: http://lis.ei.tum.de/pub-download/openrisc-builds/or1k-rtems/ | 15:23 |
| wallento | next will be rtems and linux temselves | 15:23 |
| * juliusb applauds | 15:24 | |
| juliusb | that's pretty cool! | 15:24 |
| wallento | thanks | 15:27 |
| wallento | for both musl and rtems there is nothing like continuous integration at the moment | 15:28 |
| wallento | but I think having on-demand builds for certain versions/version combinations is sufficient for now | 15:29 |
| ysionneau | great :) | 15:36 |
| Me1234 | poke53282: jor1k.com/jor1k-toolchain.tar.bz2 uses linux from openrisc.net, which is unavailable. | 16:52 |
| juliusb | wallento: that is beer-worthy | 18:17 |
| olofk | stekern: 14 branches in your orpsoc-cores repo. I'm impressed :) | 21:24 |
| -!- FreezingAlt is now known as FreezingCold | 22:33 | |
| --- Log closed Fri Feb 13 00:00:39 2015 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!