--- Log opened Fri Apr 07 00:00:18 2017 | ||
-!- [X-Scale] is now known as X-Scale | 06:42 | |
wbx | shorne: no. i was busy @ customer last two days.. | 14:36 |
---|---|---|
wbx | shorne: i check, thx! | 14:48 |
shorne | wbx: you can see here https://github.com/stffrdhrn/qemu/commits/or1k-next (if you didnt find) | 16:47 |
shorne | fixed smp toggle for openocd | 19:06 |
shorne | took me too long | 19:06 |
shorne | mithro: I am not really sure when I can get free, its always just inbetween when I get random free time | 19:07 |
shorne | i.e. early morning, late nite, when family takes naps :) | 19:07 |
shorne | From your mail is seems you have a lot of different things to look at, where to start? do you want me to try and boot on your qemu? | 19:08 |
shorne | one thing is, or1k will boot from 0x100 on reset, if your memory is at 0x4000000 how will that work? | 19:09 |
mithro | shorne: our reset location is different | 19:41 |
mithro | I'll be around in an hour | 20:37 |
shorne_ | mithro: alright, the 2 things we would need to start with is 1 making sure memory regions are recognized, 2 making sure serial driver is working | 21:30 |
-!- shorne_ is now known as shorne | 21:31 | |
shorne | the memory (0x40000000 region) is first mapped by of devicetree scan (setting up memblock) | 21:32 |
shorne | during early scan... but before that openrisc kernel does have some hard coded pyhsical addresses | 21:32 |
shorne | I guess thats why you were asking about the mapping for? | 21:33 |
mithro | Yeah | 21:33 |
mithro | I was trying to track down / understand possible hard coded physical memory addresses | 21:33 |
mithro | I should be at a computer in about 10ish minutes | 21:35 |
futarisIRCcloud | I'm working on the Lite-X serial driver at the moment. I modified the or1ksim model and added a lite-x uart to that to make it easier. | 21:36 |
shorne | futarisIRCcloud: cool | 21:46 |
shorne | for memory address, there is this part in head.S (#define tophys(rd,rs) ) | 21:46 |
mithro | Okay, I'm around now | 21:46 |
shorne | the kernel is assembled at 0xc0000000, offset, and this just hardcodes to say physical at 0 | 21:47 |
futarisIRCcloud | There is some code that emergency prints to the openrisc uart, in head.S. (for Loading Linux ... / and kernel panics) . I commented that out. | 21:47 |
shorne | i.e. address - 0xc0000000 | 21:47 |
mithro | The code currently looks like | 21:48 |
mithro | #define tophys(rd,rs)\ | 21:48 |
mithro | l.movhird,hi(-KERNELBASE);\ | 21:48 |
mithro | l.addrd,rd,rs | 21:48 |
mithro | What are rd/rs? | 21:48 |
shorne | well, source destination | 21:49 |
mithro | It looks like "arch/openrisc/include/asm/page.h:#define KERNELBASE PAGE_OFFSET" | 21:50 |
shorne | retisters | 21:50 |
shorne | i.e. tophys(r10,r11), will convert r11 logical address to physical and put it into r10 | 21:50 |
mithro | tophys(<source register with virtual address>, <destination register which should end up with physical address>) ? | 21:50 |
shorne | yes | 21:51 |
shorne | thats used throughout to map the virtual addresses of symbols and stuff | 21:51 |
shorne | until real mm is up | 21:51 |
shorne | #define PAGE_OFFSET 0xc0000000 | 21:52 |
mithro | It seems like PAGE_OFFSET in our case would be the DDR base address? | 21:53 |
futarisIRCcloud | arch/openrisc/include/asm/page.h | 21:53 |
mithro | What was confusing me a little bit was that 0xc0000000 is also used for the 3gb userspace, 1gb kernel space memory split? | 21:54 |
shorne | I think these are the offsets of the object symbols... on all my targets the memory has been at 0x0000000 | 21:55 |
shorne | i.e. from de0_nano wishbone offset | 21:56 |
shorne | [slave sdram_dbus] | 21:56 |
shorne | offset=0 | 21:56 |
shorne | I think you are right about the user/kernel split | 21:57 |
shorne | that is why its like that | 21:57 |
mithro | Well shenki was claiming that :-P | 21:57 |
mithro | shorne: The tophys function currently just clobbers the high part of the address with the high part of -KERNELBASE ? | 21:58 |
shorne | you can see why its like that in here, arch/openrisc/kernel/vmlinux.lds.S | 21:58 |
shorne | the symbols are linked also with the page_offset | 21:58 |
shorne | . = LOAD_BASE ; | 21:59 |
mithro | There seem to be | 21:59 |
shorne | .text : AT(ADDR(.text) - LOAD_OFFSET) | 21:59 |
mithro | # define LOAD_OFFSET PAGE_OFFSET | 21:59 |
mithro | # define LOAD_BASE PAGE_OFFSET | 21:59 |
shorne | mithro: the movhi, actually does set lower 16-bits to 0 | 22:01 |
shorne | I think | 22:01 |
shorne | The 16-bit immediate value is zero-extended, shifted left by 16 bits, and placed into general-purpose register rD. | 22:01 |
shorne | (from spec) | 22:01 |
mithro | Is there a good description of the openrisc ASM somewhere? | 22:03 |
shorne | yeah | 22:03 |
shorne | https://raw.githubusercontent.com/openrisc/doc/master/openrisc-arch-1.1-rev0.pdf | 22:03 |
shorne | you can always find here: https://openrisc.io/architecture | 22:04 |
futarisIRCcloud | 👍 | 22:04 |
mithro | The 16-bit immediate value is zero-extended, shifted left by 16 bits, and placed into general-purpose register rD. | 22:04 |
mithro | Oh | 22:04 |
mithro | It's the other way around | 22:04 |
mithro | tophys(<**destination** register which should end up with physical address>, <**source** register with virtual address>) ? | 22:05 |
mithro | So, it's effectively taking away PAGE_OFFSET mapping 0xc00... to 0x0 | 22:06 |
shorne | is it? its basically topysh (rd, rs) { rd = rs - PAGE_OFFSET } | 22:07 |
shorne | yes | 22:07 |
shorne | yes, to both | 22:07 |
mithro | I'm quickly reading https://linux-mm.org/VirtualMemory | 22:08 |
shorne | so you would probably want {rd = DDR_BASE + (rs - PAGE_OFFSE) } | 22:08 |
shorne | since this assmes 0x0 base | 22:08 |
shorne | yeah, thats a good refeence, I should probably read too, I havent done mm stuff for a while :) | 22:10 |
shorne | sorry, got to go, hope it helps | 22:10 |
mithro | Yeah thanks! | 22:10 |
mithro | Does a lot | 22:10 |
mithro | Looking at http://lxr.free-electrons.com/source/arch/powerpc/include/asm/page.h#L59 seems to describe how a bunch of things related to each other | 22:11 |
mithro | I'm a bit confused, I loaded the kernel into the DDR using gdb - but the first instruction seems to be "l.j 0x40000000" | 22:53 |
mithro | Loading section .text, size 0x2b8100 lma 0x40000000 | 22:54 |
mithro | I'm assuming that it's because it's assuming that the reset location is 0x100 | 22:56 |
mithro | Looks like I'm hitting an invalid instruction... | 23:11 |
mithro | Helps if I don't try and use a lm32 BIOS on an or1k kernel :-P | 23:32 |
--- Log closed Sat Apr 08 00:00:20 2017 |
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!