--- Mon Oct 7 2013 | 00:00 | |
ysionneau | can't you put expressions instead of constants in assembly? like mvhi r1, hi(some_symbol) + 0x40 | 14:27 |
---|---|---|
ysionneau | ? | 14:27 |
larsc | you can | 14:27 |
wpwrak | there are some limitations on what you can do with external symbols, since they are resolved by the linker not the assembler | 14:29 |
ysionneau | I get assembler error | 14:29 |
ysionneau | Error: junk at end of line | 14:29 |
larsc | but why do you want to add something to the hi part of the address? | 14:31 |
ysionneau | I link my kernel at address 0xc0000000 | 14:32 |
larsc | I suppose you could move the math to the linker script | 14:33 |
ysionneau | but for some low level subroutines I need to use the physical addresses | 14:33 |
ysionneau | so subtract 0xc000 and add 0x4000 | 14:33 |
larsc | crazy stugg | 14:33 |
larsc | stuff | 14:33 |
larsc | ;) | 14:34 |
ysionneau | maybe, but I did not find a better way (for now) | 14:34 |
larsc | but as I said you can probably do this in the linker script "some_address_phys = some_address + 0x400000" | 14:34 |
ysionneau | oh ok via the PROVIDE stuff? | 14:36 |
larsc | PROVIDE? | 14:36 |
ysionneau | PROVIDE( physical_XX = XX - a + b) | 14:36 |
ysionneau | ; | 14:36 |
larsc | not sure, that is maybe a bsd specific thing | 14:36 |
ysionneau | https://github.com/fallen/milkymist-mmu/blob/mmu/software/bios/linker.ld | 14:36 |
ysionneau | it was used in milkymist original linker script I think | 14:37 |
ysionneau | to compute the stack start address | 14:37 |
larsc | ah ok | 14:37 |
ysionneau | https://github.com/fallen/milkymist-mmu/blob/mmu/software/bios/linker.ld | 14:37 |
ysionneau | https://github.com/milkymist/milkymist/blob/master/software/bios/linker.ld#L57 | 14:37 |
ysionneau | sorry | 14:37 |
larsc | PROVICE(...) is like ... | 14:38 |
larsc | PROVIDE | 14:38 |
ysionneau | oh, ok, cool | 14:38 |
larsc | but it will only declare the symbol only if it is referenced | 14:38 |
larsc | one only to many | 14:38 |
ysionneau | hum ok that's what I'm reading | 14:39 |
ysionneau | too bad I need to add something to the linker script | 14:39 |
ysionneau | it does not seem very clean | 14:39 |
ysionneau | the code should be self sufficient :( | 14:39 |
ysionneau | moreover my symbol I am referencing is in the same .S file | 14:40 |
larsc | hm | 14:40 |
larsc | but the position is still only known on link time | 14:40 |
ysionneau | oh, right | 14:41 |
larsc | but why do you need the real addr again? | 14:41 |
ysionneau | indeed | 14:41 |
ysionneau | because I'm calling a function with MMU off | 14:41 |
ysionneau | it's in the TLB miss handler | 14:42 |
larsc | But the same function can be called with MMU on as well? | 14:42 |
ysionneau | humm I don't think I will need to call it from "MMU on" context | 14:42 |
larsc | or well, the symbol can be access with MMU on? | 14:42 |
ysionneau | In fact I don't even need to put hi(symbol_name) + A -B, I can put the physical address directly, I know it | 14:43 |
ysionneau | it wo't change | 14:43 |
ysionneau | but it's more clean that way | 14:43 |
larsc | you could create a special section for stuff that's running with the mmu off | 14:44 |
ysionneau | the thing is, I'm not loading the ELF file in qemu | 14:49 |
ysionneau | I'm doing objcopy -Obinary | 14:49 |
ysionneau | and I'm loading it as a BIOS file | 14:49 |
ysionneau | I modified Qemu to load the BIOS file at 0x4000 0000 instead of 0x86**** | 14:49 |
ysionneau | that's not something to commit in any way, but it allows me to test my kernel stuff easily | 14:50 |
ysionneau | more easily than loading a bios and then transfering the kernel | 14:50 |
ysionneau | qemu loads the kernel in memory at the right place for me :) | 14:51 |
ysionneau | maybe mwalle would have a better idea to do this kind of thing in a clean way | 14:51 |
ysionneau | ping mwalle :) | 14:51 |
larsc | and the kernel creates a mapping in the MMU at 0xc0000000? | 14:51 |
ysionneau | I plan on doing the boot in 2 phases | 14:51 |
larsc | usually the kernel runs at a static mapping, so you do not get these kinds of problems | 14:52 |
ysionneau | one that automatically resolves misses by updating the TLB with virt->virt-0xc000+0x4000 mapping | 14:52 |
ysionneau | and then when the pmap (virtual memory subsystem) has initialized the kernel page table page | 14:52 |
ysionneau | I switched to the real tlb miss handler | 14:53 |
ysionneau | which does the real normal job of checking if the virtual address is really mapped to something and updates the TLB accordingly | 14:53 |
ysionneau | 16:52 < larsc> usually the kernel runs at a static mapping, so you do not get these kinds of problems < that's the case here, the kernel will always be physically at 0x4000*** and virtually at 0xc000 | 14:54 |
ysionneau | if I understand what you mean by "static mapping" | 14:54 |
larsc | but you can't run it at 0x40000000 when the mmu is on? | 14:55 |
ysionneau | oh | 14:55 |
ysionneau | humm | 14:55 |
ysionneau | if I want to do something like 3G/1G | 14:56 |
larsc | I think there is a design flaw somewhere when you need to switch between multiple address spaces | 14:56 |
ysionneau | I need to map all the kernel stuff at >= 0xc000 0000 | 14:56 |
larsc | I see | 14:56 |
ysionneau | because kernel is also mapping in process context | 14:56 |
ysionneau | even if process cannot access it | 14:56 |
ysionneau | is also mapped* | 14:57 |
larsc | and it is not possible to retain the 0xc0000000 mapping when the mmu is "off"? | 14:57 |
ysionneau | I mean, the virtual memory context of any user space process contains the kernel mappings (at >= 0xc000 0000), because then there is no context switch | 14:58 |
ysionneau | when going into syscalls etc | 14:58 |
ysionneau | you can use the memory mapping of the process to access kernel stuff (and run kernel code) | 14:58 |
ysionneau | 16:57 < larsc> and it is not possible to retain the 0xc0000000 mapping when the mmu is "off"? < when MMU is off addresses are not translated, and 0xc000 is not in SDRAM | 15:01 |
ysionneau | for code most of the time it's OK | 15:01 |
ysionneau | since most of the code is like PIC | 15:01 |
ysionneau | except for big jumps | 15:01 |
ysionneau | but for load and stores ... | 15:01 |
larsc | yea, no pic stores and loads | 15:03 |
ysionneau | all of this is kind of hackish ... | 15:03 |
ysionneau | but the more I read kernel code the more I think all low level MD parts are kind of hackish anyway | 15:04 |
larsc | only in the bsd land ;) | 15:04 |
ysionneau | OpenRISC is doing this kind of trick for instance (the 2 phases boot) for their linux port | 15:04 |
ysionneau | ahah no | 15:04 |
ysionneau | bsd code is very clean | 15:04 |
ysionneau | OpenRISC rewrites the code of the TLB miss handler | 15:05 |
ysionneau | which is just a jump | 15:05 |
ysionneau | to make the jump go to the second miss handler | 15:05 |
ysionneau | that can sound hackish as well | 15:05 |
ysionneau | but ... who cares, as long as it works | 15:05 |
ysionneau | and it helps a lot to have a dummy miss handler during the bootstrap | 15:06 |
ysionneau | for LM32 I could use two memory zones for the handlers by playing with EBA... | 15:06 |
ysionneau | but I think it's even more hackish | 15:06 |
ysionneau | and it wastes even more memory | 15:06 |
mwalle | ysionneau: why dont you use the -kernel parameter? | 16:45 |
ysionneau | mwalle: because I need to link my kernel to its virtual address | 17:17 |
ysionneau | not its physical address | 17:17 |
ysionneau | then in the ELF, all addresses are like 0xc000**** | 17:18 |
ysionneau | maybe I missed something, but I think qemu cannot load the generated ELF, since it thinks RAM is 0x40000000->0x480000 | 17:19 |
ysionneau | tell me if I'm telling bullshit :) | 17:21 |
mwalle | ysionneau: mh, how does the linux kernel do it? | 17:45 |
larsc | does not use the mmu | 17:46 |
mwalle | larsc: on other architectures | 17:48 |
mwalle | mhh and isnt there a load address for each elf segment? | 17:55 |
larsc | doesn't need to switch | 17:55 |
mwalle | larsc: iirc, on arm the mmu is turned off (if turned on) by the bootloader and the memory base is 0x0 | 17:56 |
larsc | turned off if turned on? | 18:00 |
mwalle | larsc: if the bootloaded uses the mmu it is turned off before starting the operating system | 18:01 |
mwalle | if it is not used it remains disabled | 18:02 |
larsc | ah | 18:02 |
mwalle | ysionneau: "$(CROSS)readelf -l netbsd_kernel" should print the virtaddr and physaddr of the elf file | 18:03 |
mwalle | and arm does not have fancy features like mips where some segements are remapped to 0x0 like kseg2, does it? | 18:05 |
larsc | I don't think so | 18:07 |
larsc | http://lxr.free-electrons.com/source/arch/arm/kernel/head.S#L59 | 18:09 |
Action: ysionneau back from diner | 19:25 | |
ysionneau | 19:45 < mwalle> ysionneau: mh, how does the linux kernel do it? < I honestly don't know :( | 19:29 |
ysionneau | mwalle: oh great, readelf -l tells me virt address == phys address == 0xc0****** | 19:43 |
ysionneau | I wonder how I can specify 0x4000**** as physical address | 19:43 |
Action: ysionneau starts reading linker options | 20:04 | |
davidc__ | ysionneau: usually with the 'AT' stuff (checkout embedded arm linker scripts for .data) | 20:05 |
ysionneau | hum this kind of stuff ? http://www.math.utah.edu/docs/info/ld_3.html#SEC18 | 20:10 |
ysionneau | so I can use AT ( 0x40000000 ) for the first (.text) section | 20:15 |
ysionneau | and then for the following ones I do like AT ( ADDR(.previous_section) + SIZEOF(.previous_section) ) | 20:15 |
ysionneau | IIUC | 20:15 |
mwalle | gn8 | 20:16 |
ysionneau | gn8! | 20:16 |
ysionneau | hum it did not change the load address :o | 20:18 |
ysionneau | ok the build system did not run the linker since I modified no code line | 20:23 |
ysionneau | now it fails to link :) | 20:23 |
--- Tue Oct 8 2013 | 00:00 |
Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!