IRC logs for #openrisc Monday, 2013-06-24

--- Log opened Mon Jun 24 00:00:57 2013
stekernolofk, it still doesn't and you have to invalidate the mmus too07:15
stekernoh, and you have to clear r3 too07:19
stekernand you don't need uclibc to compile the kernel07:25
olofkstekern: Can I just do make CROSS_COMPILE=or32-elf- to build linux?19:01
olofkAnd about r0, and r3 too apparently... is my only option to force them to 0 during RTL simulation?19:02
olofkOr can I do it in software somehow?19:04
olofkAnd remind me again... what was the problem with clearing r0 as the first instruction in linux? IIRC there was a patch that was rejected19:30
hnoolofk, yes. "make CROSS_COMPILE=or32-elf- ARCH=openrisc or1ksim_defconfig" then "make CROSS_COMPILE=or32-elf- ARCH=openrisc -j8", maybe menuconfig inbetween if you want to change the config.21:17
olofkhno: I tried it, but with or1k-elf-. It compiled fine after I changed the linker scripts to use elf32-or1k, and it boots up, but I'm getting some crashes21:18
* hno needs to update his toolchain...21:19
* olofk needs to cut down on the amount of openrisc toolchains currently installed21:20
hnoAnything later than 3.1 generally crashes on ordb2a for me. But I did get 3.8 running some time ago with some orpsoc/or1200/ordb2a bus & arbiter fixes.21:22
hnowill try again in some days. Currently stuck on 3.1 in a project with too little time before vacation starts.21:22
olofkIt's not like I'm doing anything more advanced than cat /proc/cpuinfo after I boot linux, so any old version works fine for me :)21:23
hnothen try openrisc-3.1 tag. Never had issues with that one.'21:24
hnoon that level...21:24
* hno have lost count of how many toolchans are installed for various arches.. 21:28
olofkHmm.. I managed to track my Linux boot in Icarus into early_init_devtree, that is called from or32_early_setup, but now the executed log isn't updating anymore21:29
olofkI must have the shareware version of or1200-monitor that only handles 70959 instructions21:30
olofkOh well. Time for bed21:30
stekernolofk: that's probably r3 (if you haven't handled that)23:16
stekernthe kernel expects a pointer to the dev tree in that register, so it's deliberately not cleared23:17
stekernand it tries to read the dev tree magic from the pointer location, so if it's x you'll just lock up23:18
--- Log closed Tue Jun 25 00:00:58 2013

Generated by 2.15.2 by Marius Gedminas - find it at!