lekernel changed the topic of #milkymist to: Mixxeo, Migen, Milkymist-ng & other Milkymist projects :: Logs: http://en.qi-hardware.com/mmlogs
mumptai has quit [Ping timeout: 245 seconds]
kristianpaul has quit [Quit: Lost terminal]
kristianpaul has joined #milkymist
kristianpaul has quit [Changing host]
kristianpaul has joined #milkymist
aeris has quit [Ping timeout: 245 seconds]
aeris has joined #milkymist
mumptai has joined #milkymist
mumptai has quit [Ping timeout: 245 seconds]
bhamilton has joined #milkymist
bhamilton has quit [Client Quit]
[florian] has quit [Ping timeout: 240 seconds]
<ysionneau> can't you put expressions instead of constants in assembly? like mvhi r1, hi(some_symbol) + 0x40
<ysionneau> ?
<larsc> you can
<wpwrak> there are some limitations on what you can do with external symbols, since they are resolved by the linker not the assembler
<ysionneau> I get assembler error
<ysionneau> Error: junk at end of line
<larsc> but why do you want to add something to the hi part of the address?
<ysionneau> I link my kernel at address 0xc0000000
<larsc> I suppose you could move the math to the linker script
<ysionneau> but for some low level subroutines I need to use the physical addresses
<ysionneau> so subtract 0xc000 and add 0x4000
<larsc> crazy stugg
<larsc> stuff
<larsc> ;)
<ysionneau> maybe, but I did not find a better way (for now)
<larsc> but as I said you can probably do this in the linker script "some_address_phys = some_address + 0x400000"
<ysionneau> oh ok via the PROVIDE stuff?
<larsc> PROVIDE?
<ysionneau> PROVIDE( physical_XX = XX - a + b)
<ysionneau> ;
<larsc> not sure, that is maybe a bsd specific thing
<ysionneau> it was used in milkymist original linker script I think
<ysionneau> to compute the stack start address
<larsc> ah ok
<ysionneau> sorry
<larsc> PROVICE(...) is like ...
<larsc> PROVIDE
<ysionneau> oh, ok, cool
<larsc> but it will only declare the symbol only if it is referenced
<larsc> one only to many
<ysionneau> hum ok that's what I'm reading
<ysionneau> too bad I need to add something to the linker script
<ysionneau> it does not seem very clean
<ysionneau> the code should be self sufficient :(
<ysionneau> moreover my symbol I am referencing is in the same .S file
<larsc> hm
<larsc> but the position is still only known on link time
<ysionneau> oh, right
<larsc> but why do you need the real addr again?
<ysionneau> indeed
<ysionneau> because I'm calling a function with MMU off
<ysionneau> it's in the TLB miss handler
<larsc> But the same function can be called with MMU on as well?
<ysionneau> humm I don't think I will need to call it from "MMU on" context
<larsc> or well, the symbol can be access with MMU on?
<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
<ysionneau> it wo't change
<ysionneau> but it's more clean that way
<larsc> you could create a special section for stuff that's running with the mmu off
<ysionneau> the thing is, I'm not loading the ELF file in qemu
<ysionneau> I'm doing objcopy -Obinary
<ysionneau> and I'm loading it as a BIOS file
<ysionneau> I modified Qemu to load the BIOS file at 0x4000 0000 instead of 0x86****
<ysionneau> that's not something to commit in any way, but it allows me to test my kernel stuff easily
<ysionneau> more easily than loading a bios and then transfering the kernel
<ysionneau> qemu loads the kernel in memory at the right place for me :)
<ysionneau> maybe mwalle would have a better idea to do this kind of thing in a clean way
<ysionneau> ping mwalle :)
<larsc> and the kernel creates a mapping in the MMU at 0xc0000000?
<ysionneau> I plan on doing the boot in 2 phases
<larsc> usually the kernel runs at a static mapping, so you do not get these kinds of problems
<ysionneau> one that automatically resolves misses by updating the TLB with virt->virt-0xc000+0x4000 mapping
<ysionneau> and then when the pmap (virtual memory subsystem) has initialized the kernel page table page
<ysionneau> I switched to the real tlb miss handler
<ysionneau> which does the real normal job of checking if the virtual address is really mapped to something and updates the TLB accordingly
<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
<ysionneau> if I understand what you mean by "static mapping"
<larsc> but you can't run it at 0x40000000 when the mmu is on?
<ysionneau> oh
<ysionneau> humm
<ysionneau> if I want to do something like 3G/1G
<larsc> I think there is a design flaw somewhere when you need to switch between multiple address spaces
<ysionneau> I need to map all the kernel stuff at >= 0xc000 0000
<larsc> I see
<ysionneau> because kernel is also mapping in process context
<ysionneau> even if process cannot access it
<ysionneau> is also mapped*
<larsc> and it is not possible to retain the 0xc0000000 mapping when the mmu is "off"?
<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
<ysionneau> when going into syscalls etc
<ysionneau> you can use the memory mapping of the process to access kernel stuff (and run kernel code)
<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
<ysionneau> for code most of the time it's OK
<ysionneau> since most of the code is like PIC
<ysionneau> except for big jumps
<ysionneau> but for load and stores ...
<larsc> yea, no pic stores and loads
<ysionneau> all of this is kind of hackish ...
<ysionneau> but the more I read kernel code the more I think all low level MD parts are kind of hackish anyway
<larsc> only in the bsd land ;)
<ysionneau> OpenRISC is doing this kind of trick for instance (the 2 phases boot) for their linux port
<ysionneau> ahah no
<ysionneau> bsd code is very clean
<ysionneau> OpenRISC rewrites the code of the TLB miss handler
<ysionneau> which is just a jump
<ysionneau> to make the jump go to the second miss handler
<ysionneau> that can sound hackish as well
<ysionneau> but ... who cares, as long as it works
<ysionneau> and it helps a lot to have a dummy miss handler during the bootstrap
<ysionneau> for LM32 I could use two memory zones for the handlers by playing with EBA...
<ysionneau> but I think it's even more hackish
<ysionneau> and it wastes even more memory
antgreen has joined #milkymist
kyak has quit []
kyak has joined #milkymist
kyak has quit [Changing host]
kyak has joined #milkymist
bhamilton has joined #milkymist
bhamilton has quit [Client Quit]
kilae has joined #milkymist
<mwalle> ysionneau: why dont you use the -kernel parameter?
<ysionneau> mwalle: because I need to link my kernel to its virtual address
<ysionneau> not its physical address
<ysionneau> then in the ELF, all addresses are like 0xc000****
<ysionneau> maybe I missed something, but I think qemu cannot load the generated ELF, since it thinks RAM is 0x40000000->0x480000
<ysionneau> tell me if I'm telling bullshit :)
<mwalle> ysionneau: mh, how does the linux kernel do it?
<larsc> does not use the mmu
mumptai has joined #milkymist
<mwalle> larsc: on other architectures
<mwalle> mhh and isnt there a load address for each elf segment?
<larsc> doesn't need to switch
<mwalle> larsc: iirc, on arm the mmu is turned off (if turned on) by the bootloader and the memory base is 0x0
<larsc> turned off if turned on?
<mwalle> larsc: if the bootloaded uses the mmu it is turned off before starting the operating system
<mwalle> if it is not used it remains disabled
<larsc> ah
<mwalle> ysionneau: "$(CROSS)readelf -l netbsd_kernel" should print the virtaddr and physaddr of the elf file
<mwalle> and arm does not have fancy features like mips where some segements are remapped to 0x0 like kseg2, does it?
<larsc> I don't think so
* ysionneau back from diner
<ysionneau> 19:45 < mwalle> ysionneau: mh, how does the linux kernel do it? < I honestly don't know :(
<ysionneau> mwalle: oh great, readelf -l tells me virt address == phys address == 0xc0******
<ysionneau> I wonder how I can specify 0x4000**** as physical address
* ysionneau starts reading linker options
<davidc__> ysionneau: usually with the 'AT' stuff (checkout embedded arm linker scripts for .data)
<ysionneau> hum this kind of stuff ? http://www.math.utah.edu/docs/info/ld_3.html#SEC18
<ysionneau> so I can use AT ( 0x40000000 ) for the first (.text) section
<ysionneau> and then for the following ones I do like AT ( ADDR(.previous_section) + SIZEOF(.previous_section) )
<ysionneau> IIUC
kilae has quit [Quit: ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]]
<mwalle> gn8
<ysionneau> gn8!
<ysionneau> hum it did not change the load address :o
<ysionneau> ok the build system did not run the linker since I modified no code line
<ysionneau> now it fails to link :)
azonenberg has quit [Ping timeout: 245 seconds]
azonenberg has joined #milkymist
mumptai has quit [Ping timeout: 240 seconds]