IRC logs for #openrisc Friday, 2017-04-07

--- Log opened Fri Apr 07 00:00:18 2017
-!- [X-Scale] is now known as X-Scale06:42
wbxshorne: no. i was busy @ customer last two days..14:36
wbxshorne: i check, thx!14:48
shornewbx: you can see here https://github.com/stffrdhrn/qemu/commits/or1k-next (if you didnt find)16:47
shornefixed smp toggle for openocd19:06
shornetook me too long19:06
shornemithro: I am not really sure when I can get free, its always just inbetween when I get random free time19:07
shornei.e. early morning, late nite, when family takes naps :)19:07
shorneFrom 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
shorneone thing is, or1k will boot from 0x100 on reset, if your memory is at 0x4000000 how will that work?19:09
mithroshorne: our reset location is different19:41
mithroI'll be around in an hour20: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 working21:30
-!- shorne_ is now known as shorne21:31
shornethe memory (0x40000000 region) is first mapped by of devicetree scan (setting up memblock)21:32
shorneduring early scan... but before that openrisc kernel does have some hard coded pyhsical addresses21:32
shorneI guess thats why you were asking about the mapping for?21:33
mithroYeah21:33
mithroI was trying to track down / understand possible hard coded physical memory addresses21:33
mithroI should be at a computer in about 10ish minutes21:35
futarisIRCcloudI'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
shornefutarisIRCcloud: cool21:46
shornefor memory address, there is this part in head.S (#define tophys(rd,rs) )21:46
mithroOkay, I'm around now21:46
shornethe kernel is assembled at 0xc0000000, offset, and this just hardcodes to say physical at 021:47
futarisIRCcloudThere 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
shornei.e. address - 0xc000000021:47
mithroThe code currently looks like21:48
mithro#define tophys(rd,rs)\21:48
mithrol.movhird,hi(-KERNELBASE);\21:48
mithrol.addrd,rd,rs21:48
mithroWhat are rd/rs?21:48
shornewell, source destination21:49
mithroIt looks like "arch/openrisc/include/asm/page.h:#define KERNELBASE     PAGE_OFFSET"21:50
shorneretisters21:50
shornei.e. tophys(r10,r11), will convert r11 logical address to physical and put it into r1021:50
mithrotophys(<source register with virtual address>, <destination register which should end up with physical address>) ?21:50
shorneyes21:51
shornethats used throughout to map the virtual addresses of symbols and stuff21:51
shorneuntil real mm is up21:51
shorne#define PAGE_OFFSET     0xc000000021:52
mithroIt seems like PAGE_OFFSET  in our case would be the DDR base address?21:53
futarisIRCcloudarch/openrisc/include/asm/page.h21:53
mithroWhat was confusing me a little bit was that 0xc0000000 is also used for the 3gb userspace, 1gb kernel space memory split?21:54
shorneI think these are the offsets of the object symbols... on all my targets the memory has been at 0x000000021:55
shornei.e. from de0_nano wishbone offset21:56
shorne[slave sdram_dbus]21:56
shorneoffset=021:56
shorneI think you are right about the user/kernel split21:57
shornethat is why its like that21:57
mithroWell shenki was claiming that :-P21:57
mithroshorne: The tophys function currently just clobbers the high part of the address with the high part of -KERNELBASE ?21:58
shorneyou can see why its like that in here, arch/openrisc/kernel/vmlinux.lds.S21:58
shornethe symbols are linked also with the page_offset21:58
shorne. = LOAD_BASE ;21:59
mithroThere seem to be21:59
shorne.text                   : AT(ADDR(.text) - LOAD_OFFSET)21:59
mithro#  define LOAD_OFFSET  PAGE_OFFSET21:59
mithro#  define LOAD_BASE    PAGE_OFFSET21:59
shornemithro: the movhi, actually does set lower 16-bits to 022:01
shorneI think22:01
shorneThe 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
mithroIs there a good description of the openrisc ASM somewhere?22:03
shorneyeah22:03
shornehttps://raw.githubusercontent.com/openrisc/doc/master/openrisc-arch-1.1-rev0.pdf22:03
shorneyou can always find here: https://openrisc.io/architecture22:04
futarisIRCcloud👍22:04
mithroThe 16-bit immediate value is zero-extended, shifted left by 16 bits, and placed into general-purpose register rD.22:04
mithroOh22:04
mithroIt's the other way around22:04
mithrotophys(<**destination** register which should end up with physical address>, <**source** register with virtual address>) ?22:05
mithroSo, it's effectively taking away PAGE_OFFSET mapping 0xc00... to 0x022:06
shorneis it?   its basically  topysh (rd, rs) { rd = rs - PAGE_OFFSET }22:07
shorneyes22:07
shorneyes, to both22:07
mithroI'm quickly reading https://linux-mm.org/VirtualMemory22:08
shorneso you would probably want {rd = DDR_BASE + (rs - PAGE_OFFSE) }22:08
shornesince this assmes 0x0 base22:08
shorneyeah, thats a good refeence, I should probably read too, I havent done mm stuff for a while :)22:10
shornesorry, got to go, hope it helps22:10
mithroYeah thanks!22:10
mithroDoes a lot22:10
mithroLooking 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 other22:11
mithroI'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
mithroLoading section .text, size 0x2b8100 lma 0x4000000022:54
mithroI'm assuming that it's because it's assuming that the reset location is 0x10022:56
mithroLooks like I'm hitting an invalid instruction...23:11
mithroHelps if I don't try and use a lm32 BIOS on an or1k kernel :-P23: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!